OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: question re Users for repository vendors


I am curious to see whether our repository (HP Trim) is the only one with the following CMIS mismatch.

 

The only information CMIS presents for a user is the principal ID, under the assumption that all users (and groups) are in the corporate directory.

 

This is fine for people but HP Trim uses groups extensively.  These groups are not from the corporate directory but exist only in HP Trim’s internal directory.

 

While for a user we can use their login name as their principal ID I cannot determine how we could usefully identify a group as the internal HP Trim ID is meaningless without access to Trim, and the group’s name is not a unique identifier.  Plus we have no service to get a list of these groups.

 

So, for example, if we supported groups a CMIS user wanting to apply an ACL to a Trim group would have to know that ‘Trim_Group_56435’ is the group they want.

 

Does anyone else have this model where the repository user directory is a superset of the corporate directory?  In particular where there are groups in the repository directory that do not exist outside the repository.

 

If yes have I missed an obvious solution to my problem?

 

If no I will just have to live with it I suppose.

 

 

 

Thanks,

 

 

David Churchland

HP



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]