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.