TableReferences in Directories : can we extend the schema?

Hello everyone,

I'm actually playing with directories and table references. I have no problem with “basic” use of tableReference.

My problem is that i would like to add some additional information in the reference table. Let's take an example with two directories : profile and function (the content of these directories doesn't really matter).

Let's check the contrib :

<directory name="profile">
        <tableReference field="functions" directory="function"
                table="profile2function" sourceColumn="profileId" targetColumn="functionId
                schema="profile2function" dataFile="directories/profile2function.csv" />

It works perfectly when i only need a mapping/reference table with [profileId, functionId]. But I would like to add an additional metadata in this mapping, let's say “status”.

I tried to create a schema profile2function.xsd with profileId, functionId and status. I also added it to the required contribution.

Well, it seems that it doesn't work like I expected, because when i try to access the directory (in admin center, for example), I get an exception saying “column not found: status” while loading the csv file. (because i put the additional column in the csv file, of course)

So my question is : am I misunderstanding the meaning of schema in tableReference? Maybe this schema field doesn't have this purpose, and we're not able to extend this mapping table?
Or do you think i did a mistake somewhere?

If I take a look at the method getTable() of TableReference, i can see that we only add the sourceColumn and targetColumn here. We could maybe play with the extended schema in this method, to add the additional columns?

Maybe it would be easier to create our own extended mapping table, and handling manually the id references, but i don't like this approach.

Thank you.

0 votes

1 answers




Table references only handle a limited set of use cases, complex schemas are not always supported and i guess you're running into one of the limitations.

Defining new table references is an option, but it can be tricky to implement, and you may run into other limitations of the directory service API.

If you do not need to retrieve that kind of information from an external directory, you might want to consider persisting this information in documents in the Nuxeo repository instead.

As you're describing a “profiles” or “roles” feature, you might be interested in using computed groups and security policies to make the link between these settings and security/filter checks in the application.

0 votes

I've decided to persist this information in documents. I was thinking about this solution, but I wanted to be sure about directories.

The terms profile/roles are misleading. It was just an example and didn't wanted to say directoryA/directoryB :-)

Thank you.