[#CMIS-724] Users and Groups - OASIS Technical Committees Issue Tracker

OASIS Content Management Interoperability Services (CMIS) TC

Users and Groups

Created: 06/Jul/11 08:13 PM Updated: 22/Mar/12 05:05 AM

Component/s:

Schema

Affects Version/s:

Proposals for 2.0

Fix Version/s:

None

Proposal:	If issue 723 is supported we make users and groups standard object types. Preferrably there would be a way that groups could contain users.
Resolution:	Deferred to 2.0 (5 March 2012)

Description

« Hide

Issue 723 proposes a way to model objecs other than the current four core types. A prominent theme within that discussion has become the requirement to model users and groups. I believe the users and groups issue requires a thread of its own, hence this new issue.

There are two problems I see driving this request:

1) Repositories often have internal groups. t the moment, if a CMIS consumer wishes to apply an ACL to an internal group there is no way for the CMIS consumer to discover that group.

2) Documents often have relationships with not only other documents but also people. These people can not always be represented by a simple string (e.g. a network ID). I believe we need a way to model a user in CMIS so that we can relate a Document to the person. For example the Document 'Parking ticket' was issued to the 'Person' Ralph Bellamy. I kinow it is possible to use cmis:Document to model a person but I think there are problems with this.

All

Comments

Change History

Sort Order:

[ Permalink | « Hide ]

David Churchland added a comment - 14/Jul/11 06:41 PM

An objection raised in the latest TC meeting was brought that users and groups are not exclusive to content management and belong outside the CMIS standard. Maybe users and groups are the wrong words. In HP Trim we call them Locations, and the Location of a document is very important to a Trim user. There are a host of relationships that we track between a piece of content and various locations (which may be 'users' who exist in an external directory). I know that we are not unique in this and that at least one other repository has mapped these 'Locations' as Documents.

If CMIS is better without this then so be it. I suppose I am motivated by the vision of a person using a CMIS client who can see that something (a person, a group, an organisation?) has a particular relationship with this Document but, because the CMIS client software has not built a Trim specific add-in to retrieve more information all they can see is a cryptic principalId.

[ Permalink | « Hide ]

David Churchland added a comment - 03/Aug/11 06:02 PM

Maybe some scenarios will clarify my thinking...
Using the browser binding and I wish to display the document owner name, I would rather not contemplate consuming LDAP from a web browser.
In a Local council implementation I wish to define a relationship between a resident and a document sent to them. If there was a standard 'cmis:person', which inherited from cmis:custom, then the resident could be defined as a cmis:person.
Irrespective of best practice our customers routinely create groups internal to HP Trim. I would like to be able to do a SELECT * FROM cmis:group. Then use the id of the cmis:group to apply ACLs for that group.

As I said in the last call I initiated this topic in response to the proposal for a custom object type (JIRA 723). If it was possible to create custom object types I would be very tempted to create person.
So my question is, would any other repository even be tempted to create a custom person object type if JIRA 723 made it viable? If yes shall we discuss a standard approach, if no then I will wait to see what comes of JIRA 723 and make my choices then.

[ Permalink | « Hide ]

David Choy added a comment - 05/Aug/11 12:15 PM

Can "document" objects be used for this purpose? While the terminology may be misleading, the "document" type was intended to represent generic, independent information entities, not just documents in the conventional sense. (There was a big debate on the terminology in the early days but no one was able to come up with an ideal name for this type. In the end, the choice was semi-arbitrary.)
Granted, the document type is a bit heavy. But with secondary types, maybe some of the document type's properties can be redefined as secondary types so that the document primary type can be lighter. This is probably a v2.0 discussion.

For the four root types in 1.0, each exhibits a different behavior (a different set of methods), while no new method is allowed for subtype. Is there a need for new methods for users and groups?