[Zope-dev] Permission

[Jim Fulton]

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.