[Zope-dev] Permission

[Tom Deprez]

>> B)Assume I want to give Anonymous the right to 'Add Folders'
>> 
>> Then I only have to check the 'Add Folders' permission for Anonymous and
>> the permission will be granted to Anonymous (even, although in the
>> root-folder Anonymous doesn't has the right?
>
>Right.
>
>> Acquisition doesn't takes
>> part, although it is still check for 'Add Folders'?)
>
>Yes and no. Since everyone has the anonymous role, Zope
>won't bother checking containing folders if anonymous is granted access.

aha, yes! everybody has the anonymous role, so the permissions a certain
person has, is the sum of the anonymous permissions and the permission to
his/her role (if a role is assigned to the person)

mmm. Ok, let's assume we've made a RoleB which is in fact just the same as
anonymous and we imply this example on situation B: 

RoleB doesn't has the permission 'Add Folders' in Root (neither does
anonymous). And in private, we want to give RoleB the right to 'Add Folders'.

Then I only have to check the 'Add Folders' permission for RoleB and the
permission will be granted to RoleB, in 'private'. Even, RoleB doesn't has
the right to 'Add Folder' in 'root' and acquire permissions is set in
'private' for 'Add Folder'

>> If above is correct, then I was wrong in my thinking for situation B. But
>> then where stands acquisition for this situation? It is checked for 'Add
>> Folders', so it should get it's permission from 'root' and not from
'private'.
>
>You've lost me. If you are saying that granting anonymous a permission
>makes acquirintg settings for that permission irrelevent, you are right.

So, what I don't understand is this (if my assumption with B is correct):
In 'private', the acquire permission is checked for 'Add Role'. In 'root',
RoleB doesn't has the permission to 'Add Folder'. So, since we set that
permission is acquired, RoleB would normally not have the permission to
'Add Folder'. However, in 'private', we've given RoleB the permission to
'Add Folder', so RoleB has the permission 'Add Folder'. Doesn't this breaks
the acquire rule? We say that 'Add Role' must be acquired from above, but
Zope doesn't looks further than 'private' since 'Add Folder' is given to
RoleB in 'private'.

>> I was more talking about another view to the permission roles. Iside Zope
>> you would still need to have the acquire permission boolean. However, this
>> would be attached to every role per container. Instead of one acquire
>> permission column, you would have an acquire permission column for every
>> role per container. This would eliminate the things wich happend with RoleA
>> (see above), because the acquire permission is still checked for RoleA for
>> this container.
>> 
>> Off course having a second column of checkboxes (acquire permission) would
>> confuse even more. Therefor the proposition of handling the acquire
>> permission automatically behind the scenes. But perhaps this isn't possible
>> when situation 'B' is possible.
>
>Another possibility would be at provide an option to deny access.
>Then you could deny access to view in example A without affecting
>RoleA.

So, you mean with 'deny access' a new permission 'deny view'? Sorry, you've
lost me here.

>> >By acquiring permission settings you are allowing containers to
>> >grant a permission to a role today or sometime in the future.
>> >This allows someone to control permissions in a centralized fashion.
>> 
>> Sorry, I don't understand above sentence.
>
>The point is that the acquisition is done dynamically when permissions
>are checked. Suppose I acquire the permission settings for the "Add
>Folder" permission. Today, that may mean I acquire the ability for 
>"Owners" to add folders. Tomorrow, someone may also grand "Add Folder"
>to members. I'll acquire that as well, automatically.

aha, this is again the sum of permissions, not? ie. permission I have today
are the sum of permissions of all my roles asigned to me.

>> ----
>> 
>> Other question:
>> 
>> If acquire permission is set for RoleA (in 'private') and RoleA has the
>> 'view permission' in 'Root', then RoleA has the view permission in
>> 'private' (acquisition, not?).
>
>You cant set the "acquire permission settings" check box for roles.
>You can only set it for permissions.

Yep, you're right here. acquire permissions is for all roles. (I mixed it
up with my idea explained above. ie. an acquire permission setting for
every role per container.) Sorry.

>If the acquire permissions settings is set for the permission "View"
>in folder "private" and "RoleA" has the "View" permission in the root, then
>"RoleA" has the permission setting implicitly in folder "private".
>
>> However the checkbox at 'view permission'
>> for RoleA is not checked.
>
>Because it is not set here.

It isn't set, because the administrator knows that the view permission is
acquired from one of the containers above, thus he didn't needed to set it.

>> I it possible to put name next to this checkbox
>> which tells that permission to 'view' for RoleA is acquired from 'root', or
>> just a link which brings us directly to the security view of 'root'.
>
>That would be useful, as long as people understand that the decoration
>could change when someone changes a setting up above.

Yes, but then this name/link would change also not? The name/link would
point to the place where Zope stopped it's acquire algoritmen. And this
algoritmen stops if Zope knows for sure if the permission is granted or not. 

>> I'm thinking that this would help us a lot when we want to know from where
>> the permission is granted. Then we don't have to check all security views
>> of the parent-containers.
>
>Yes, I agree, that this would be useful. Maybe the security display
>wouldn't give the source directly but maybe a symbol with
>alt text that gives the source location and some sort of hyperlink
>to the same.

Yes, that would be nice.


Tom.