Tom Deprez wrote:
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)
Right.
Since acquire permission for view is unchecked, all roles take over the permission set for View at folder 'private' (no acquisition).
Only those roles you've checked will have the view permission of acquisition of permission settings is disabled.
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.
Right.
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.
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.
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.
Another possibility would be at provide an option to deny access. Then you could deny access to view in example A without affecting RoleA.
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.
----
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. 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.
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.
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. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.