I have this q'n already a long time in my head and I still don't know the
answer to it. It has to do with the security-view. I hope that someone can
shed a light on my brains.

Why is their an Acquire permission (referred to as acq_perm in following
text) checkbox column? 

In order to change a permission for a certain role, we have to check or
uncheck this permission at the roles permission checkbox. However, for this
to work we have to uncheck the acq_perm column (because if this one is
checked, the permission is taken from parent-folder-objects anyway, the
value of the role checkbox doesn't counts at that moment). As a drawback,
this means that all roles have to be checked/unchecked, because they don't
acquire the permission anymore from one of its parents-folder-objects.

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.

A) In the first approach we've to uncheck the acq_perm checkbox and have to
set the checkbox of every role according to how we want the permission to
be handled by that role.

B) In the second approach we've to uncheck the permission checkbox of the
role(s). Other roles are not effected.

Am I missing something here? Is my explenation somewhere wrong? Why does
Zope uses the first approach? Which, sounds for me, a little bit more

Thanks for any explanation!

Tom Deprez.

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

Reply via email to