We've built a product using Apache Chemistry and CMIS 1.1 (Java based OpenCMIS). We've also discovered that managing ACL-related items OUTSIDE of the 'CMIS band' is far better and avoids "cluttering" the Document repository with "user/group/permission" semantics -- *especially when the number of users is large (this is our case as there are many thousands).* We also have very complex role/permission requirements across many clients and users, so this made more sense for us. We don't use any of the ACL support in CMIS in our enterprise use cases.
We added 2 properties to the CMIS Document model such as a "document category" and the CMIS object that is stored holds that category (an opaque ID that we assign for a specified set of such categories). You can usually extend the cmis:Document model using whatever mechanism your ECM product provides for the CMIS *server *side implementation. That ID is also part of our separate access control layer where user permissions, etc are stored. At this point the category ID acts like a foreign key on the document record in the ECM system, that can now be checked against the access control tier/data store where permissions to such a category are maintained and remain outside of the direct ECM interaction that uses the CMIS *client* API. Just one opinion :-) *Mark * On Tue, Dec 1, 2015 at 4:49 AM, Florian Müller <f...@apache.org> wrote: > Hi Kai-Uwe, > > There have been many and long discussions about this. It's a very complex > topic. There is no common understanding of a principal, a user, a group, or > a role and the metadata around them. There are repositories that don't even > have access the user management and wouldn't be able to provide any > information about a user beyond the user ID. In an enterprise environment > you usually have a central user management system (e.g. a LDAP server) that > least provides users and groups to clients. > Defining all the concepts in the CMIS specification and a usable interface > would take weeks, if not months (and would add quite a lot more pages to > the spec). It was not worth delaying the CMIS specification for a few > months because of this. > > But feel free to join the CMIS Technical Committee and provide a proposal. > The discussions about CMIS 2.0 are just starting. > > - Florian > > > > Hi Florian, >> >> this is defiantly a weakness of CMIS in the area of DMS/Collaboration. >> Having a protocol with a standardized way to access users and groups >> would help repository vendors a lot to support the CMIS protocol. >> Users and groups are nearly the same important as documents and >> folders. >> >> Kai-Uwe >> >> >> -----Ursprüngliche Nachricht----- >> Von: Florian Müller [mailto:f...@apache.org] >> Gesendet: Montag, 30. November 2015 17:44 >> An: dev@chemistry.apache.org >> Cc: marcel.romagnu...@structr.com >> Betreff: Re: Access to the Principal List in the ACL Editor >> >> Hi Marcel, >> >> CMIS deliberately doesn't provide any user management functionalities. >> This includes listing users. There is no standardized way to get all >> repository users. >> Just getting all repository users is probably also not what you want. >> Assume a repository with 100,000 users. It wouldn't be really helpful >> to have them all in the drop-down box. >> >> >> - Florian >> >> >> >> Hello everyone, >>> >>> my name is Marcel Romagnuolo and I am using the great OpenCMIS Server >>> Framework to build a CMIS server for the CMS "Structr". >>> >>> I wanted to ask you how to get access to the Principal List in the ACL >>> Editor in the CMIS workbench (see: >>> http://www.pic-upload.de/view-28996249/ACLEditor.png.html ). >>> The Principal list only shows the Principals, who are currently listed >>> in the ACEs (+ "cmis:user" and probably the anonymous and anyone IDs). >>> The problem is, the ACEs don't always contain all Principals of the >>> repository. >>> >>> I want to list all current Principals stored in the database of the >>> repository though. With that way the user can add easily new ACEs of >>> other principals. >>> >>> Now I need to know where and how I can transfer the list of Principals >>> to the framework or if the framework manages it internally. >>> >>> Thank you for reading and best regards, Marcel >>> >> >
