Hi Nate,
My question is on a bit lower level than that. Here's a concrete
example of what I'm referring to:
When we create a new Sakai Document, a new "pooled content" item is
created. I think the idea of the "pool" is that it contains multiple
other content items that make it up, for example "pages". The content
structure would look something like this:
"ltMk1c1gJ": { // The top-level pooled content identifier
...
"id1234567": { // A page within the pooled content item
...
"rows": { // An item that defines the rows and columns that make
up the page structure
...
}
}
}
The way the permissions work, is that if I grant someone the right to
"WRITE" to ltMk1c1gJ, they effectively have permission to edit that
node, and all its children -- unless someone "denies" write access
from that user somewhere down the tree.
The problem in question is that, in order to edit a pooled content
item, this requires the ability to delete rows and columns from the
"rows" object. Assuming we don't want to assign Editors the ability to
"DELETE" the root content-pool item (inline with google-docs
permission mechanism :)), we need the ability to say that while a user
can't delete the root element, they can delete their children.
So that's where my options / questions come in:
a) If a user has "WRITE" permission on a content node, should they
always be able to delete their children? If not, what is the
difference between "WRITE" and "WRITE_PROPERTY" ("Write Property" is
another permission we have built in to our permissions framework)?
b) If the answer to a) is no, and that it is too broad of a statement
to make, maybe we need a new permission such as "DELETE_CHILDREN", so
that editors may have full access to the content (pages, widgets,
etc...) within pooled content?
c) (new) Should editors of a Sakai Document even be able to delete
pages within the document? If not, then maybe we need to just make
that 'rows' element a string instead of a content structure, so that
editing the structure of a page is an 'edit' instead of deletes and
creates.
I'm hoping that those who understand the requirements for the Editor
role can chime in, or point me towards some relevant documentation.
Thanks,
Branden
On Thu, Apr 19, 2012 at 4:10 PM, Nate Angell <[email protected]> wrote:
> If I understand what you are asking correctly...
>
> When in doubt on questions like these, I look to see how Google Docs
> has done it as I believe they have done a lot of things pretty well,
> and they sure have a lot more users and budget to test with.
>
> IIUC, in gdocs, a doc owner and any editors have different rights:
>
> 1) A doc can only have one owner.
> 2) A doc owner can transfer ownership to another user.
> 3) Only a doc owner can "trash" it.
> 3) Editors can "unsubscribe" to a document when attempting to trash it.
>
> Maybe a model like that makes sense for OAE also?
>
> = nate
>
> On Thu, Apr 19, 2012 at 10:21 AM, Branden Visser <[email protected]> wrote:
>> Hi everyone,
>>
>> I'm working on KERN-2692, which is a permission exception when trying
>> to delete content within a pooled content node of which a user has
>> edit permission. Has this scenario been taken into consideration?
>>
>> a) AccessControlManagerImpl looks scary
>> b) If a user has "WRITE" permission on a content node, should they
>> always be able to delete their children? If not, what is the
>> difference between "WRITE" and "WRITE_PROPERTY"?
>> c) If the answer to b) is no, and that it is too broad of a statement
>> to make, maybe we need a new permission such as "DELETE_CHILDREN", so
>> that editors may have full access to the content within pooled
>> content.
>>
>> Any advice is much appreciated!
>>
>> --
>> Cheers,
>> Branden
>> _______________________________________________
>> oae-dev mailing list
>> [email protected]
>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
--
Cheers,
Branden
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
