[Zope-dev] Permission

[Tom Deprez]

Thanks Jim,

for answering my q'n. 

>> In order to change a permission for a certain role, we have to check or
>> uncheck this permission at the roles permission checkbox.

>I don't understand this.  You can grant permissions to 
>a role locally, regardless of whether you acquire permission
>settings.  If you don't acquire, then the role only gets the permissions
>you set, otherwise, it *may* get permissions from above.

So, if I understand this correctly :

A)Assume I want to remove the View permission from the anonymous role in
folder 'private' (just below root-folder).

I've to uncheck the view permission for anonymous and also the acquire
permission for view (because otherwise anonymous would still have the view
permission by acquisition from root) 

Since acquire permission for view is unchecked, all roles take over the
permission set for View at folder 'private' (no acquisition). Assume I had
in root a 'RoleA' and  permission was set for View. At this moment I have
to check  the view permission for RoleA.


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? Acquisition doesn't takes
part, although it is still check for 'Add Folders'?)

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'.

>> Now, why couldn't this be implemented like the following? Isn't this easier
>> to grasp?
>> 
>> The Acq_perm column doesn't exists. Assume that acquisition of a permission
>> is always Active. The checkboxes of the role show their actual value
>> (according to the acquisition). Thus if permissionA is checked in the
>> parent-object, permissionA is also checked. If you want, for a certain role
>> that this permission is not given, you uncheck permissionA. The subobject
>> will show an unchecked permissionA box (because it acquires from its
>> parent). In order to give the subobject again the permission, we only have
>> to check permissionA.
>
>The problem with this is that it doesn't recognize changes made to containers
>later.

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.

>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.

----

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?). However the checkbox at 'view permission'
for RoleA is not checked. 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'.

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.


Thanks in advance,

Tom.