Mike, Thanks for this insight. I posted another reply based on yours and Danny's help so far. One specific thing not in that reply is about your comment regarding entitlements. In my updated description of the use case I stated that any documented in the 'shared' directory could be read by anyone that the user chooses. So, I am not sure that I would need a document to record relationships in this scenario. Your thoughts? If something is still needed could this be done with document or even directory properties? I understand that there are trade offs for each choice. I estimate that the average user will have between 2000 - 3000 documents in this shared directory and will share them with, at most 100 other users. Documents sizes will range between 100kb and 500kb.
Thanks for your help. Cheers, Tim On Mon, Jul 28, 2014 at 7:50 PM, Michael Blakeley <[email protected]> wrote: > 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 > -- ============================================ Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
