In the builtin security model, simply adding a collection to a document won't make that document visible to another user. Visibility of documents is controlled by read permissions and roles. Granting read permission for a document to a role makes that document visible to users that have that role.
Using the builtin security model, each user would have its own role, and the default permissions would include insert, read, and update for that role. Users could also grant permissions to other user roles. However that might not be optimal for some of your most common use-cases. First, re-sharing could get tricky. Re-sharing a document by changing its permissions requires updating it. That may be the trickiest part of your implementation, because if I have update permission I can make any other changes too. That might lead you to use an amp'd function for resharing, and you might have to tracking sharing state outside the builtin security model. Adding some document properties might take care of that. Also it's not clear to me how your users will think of these "collections". But let's say they look and act like folders or directories. With dropbox, for example, I can share a specific document or an entire folder. If I create a new document in a shared folder, that's also shared. That would work if you enable inherited permissions using the built-in security model, or using extra code in your upload function. However automatic inheritance requires directory fragments. But enabling automatic directory creation can be a bottleneck for concurrent updates. Maybe you could get away with directory-creation=manual, and call xdmp:directory-create only when sharing a directory. Or implement your own inheritance code that runs whenever a new document is created, and maintain your own documents that record sharing relationships. Extending that idea, another approach is to maintain your own pseudo-security model. This is sometimes called "entitlements". This is closer to how dropbox works, and it has pros and cons. You have more flexibility, but any bugs in your code risk revealing documents that ought not to be shared. In this model you would maintain your own documents that record sharing relationships. When requesting a document or directory you'd use that sharing information to build a query using cts:document-query, cts:directory-query, and perhaps even cts:collection-query. The query results will only include documents that the user is authorized to see. This is very similar to how the built-in security model works, but using your own data model rather than directory fragments. -- Mike On 28 Jul 2014, at 07:18 , Timothy W. Cook <[email protected]> wrote: > I am in the early design stages of a (hopefully) large application and would > like to see if I understand the operations of collections correctly. > > You can think of this in a similar context to a social media app. > I have attached a simple diagram to aid the text. > > Imagine that Joe, Sue and Tom are users and each have a collection (marked > 'P' )where only they have read/write access to documents they load. > Joe and Tom have collections that they would like to use to share (read only) > with various other users, one being Sue. This seems rather straight forward. > However, the use case also calls for Sue being able to share (read only) > Tom's documents with Joe and Joe's documents with Tom; as she sees fit > without the intervention of Tom or Joe. > > Could someone expand on this to describe how this might be setup? Do I need > separate roles that are tied to each collection, for each of these exchanges? > > > Thanks, > Tim > > > -- > > ============================================ > Timothy Cook > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > MLHIM http://www.mlhim.org > > <Collections.png>_______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
