Tom Deprez wrote:
>
> Hi,
>
> 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?
It allows you to honor permission settings made in containing objects.
> 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.
> 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).
You don't have to ncheck the acq_perm column if you simply want to
grant a permission to a role. You only need to uncheck the
acq_perm column if you want to prevent containing objects from
granting a permission to other roles.
> 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.
So don't uncheck the acq_perm column.
> 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.
> 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.
You don't need to uncheck the acq_perm checkbox unless you want to
prevent containers from granting permissions.
> 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
> complicated.
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.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] 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.
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
