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: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.