I would very much apreciate such an enhancment. so ++1 I would like to see where a role was assigned. And If I can express yet an other wish: I would very much like to have a way to see what the settings for a particular User is. And where the settings for a given permissions have come from. Robert Dieter Maurer wrote:

Local roles are "acquired" from ancestors.

While this is not bad for e.g. a "Manager" local role, its conceptual usefulness is in great doubt for e.g. the "Owner" role. It is very unclear why an "Owner" of a folder should automatically be an "Owner" of all its content.

I therefore propose to make "acquisition" of local roles customizable.

I see two potential variants:

1. objects get a boolean flag "__ac_acquire_local_roles__" with default value "True" which allows "acquisition" of all local roles.

2. objects get a dictionary "__ac_acquire_local_roles__" mapping role names to a boolean which allows acquisition for the respective role.

Of course, the second variant provides more fine grained control and will require a more complex UI.

The change would affect the methods "allowed" and "getRolesInContext". of "AccessControl.User.BasicUser" and would require new methods in "AccessControl.Role.RoleManager" to read and modify the new "__ac_acquire_local_roles__".

Moreover, I propose to change the local role management pages. When setting local roles, information about "acquired" local role definitions is very helpful. I therefore propose to display this information on the local role edit page.

I even would prefer a much more drastic change for both local role management and permission-role-map management: a compact look only overview mapping roles to users and permission to roles, respectively, with links to a page to edit the association of a single role or permission, respectively. Something like:

Role | acquire | locally assigned users| ancestor assigned users ------------------------------------------------------------------------- Owner | no | dieter | admin, dieter ------------------------------------------------------------------------- Manager | yes | dieter | admin -------------------------------------------------------------------------

The "Role" column is a link to a page to edit "acquire" and "locally assigned users" for the respective role.

Advantages:

* more natural behaviour for roles like "Owner"

* access restricted sub-sites would be much easier to implement

* more informative management pages

Risks:

* Classes deriving from "AccessControl.BasicUser" may have overridden "allowed" and "getRolesInContext".

Such overridden methods would not interpret "__ac_acquire_local_roles__" until adapted.

Fortunately, it is not very likely that these two methods are overridden.

* Local roles get a bit more complex.

However, explicit "acquisition" control is already used for the permission role mapping. Thus, users could recognize the same concept.

* The 2.8/2.9 edition of the Zope Book would need to be adapted.

If there is interest, I could implement the changes and provide patches against the Zope SVN version. However, I do not have write permissions to the repository. This means, someone else would need to make the actual checkins.

BTW: Almost surely, I will implement the proposed change in our "private" Zope copy and use it in one of our projects. This means, I could provide "production experience" for the change in some months.

I'm very interested in all kind of enhancements to local roles. The main use is, like you said, access-restricted subsites. Currently I've added what I call "local roles blocking" to a few user folders we use (CPSUserFolder, NuxUserGroups (code available on http://cvs.nuxeo.org)) *but* there are important problems which I'll detail below. I use blocking of local roles in the sense that a local role specified somewhere can either allow the role like today (it being acquired), or block completely acquision of this role for current and deeper objects. I guess blocking only at the exact level where the roles is present would be a straightforward extension and wouldn't change the code much. The spec for blocking I use is visible at http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/NuxUserGroups/doc/BLOCKING.txt?rev=... , simply put it says that a role prefixed with '-' means that the role is blocked instead of being granted (and acquired). We could use a prefix of '=' to say "grant only here but don't acquire". I'm using the standard __ac_local_roles__ datastructure to retain backward compatibility, so an old user folder implementation would just see additional roles with strange prefixes and wouldn't break everything when editing them. This works very well at the simple Zope level (indeed all the user folder products we use have specialized version of allowed() and getRolesInContext()). The problems begin when we add in CMF. CMF's catalog has to manage, for every object it indexes, an additional index called 'allowedRolesAndUsers' which is used to filter catalog objects by viewability. This index stores all roles having the permission View in the role/permission map, and all the users whose local role gives them this permission. But when you mix in groups of users and blocking, there's no way to make this index a simple list of roles, the datastructure has to be quite richer (mathematically, we don't have non-decreasing function of the roles available when depth increases). This means that a KeywordIndex cannot be used, and I have to used a specialized index whose computation a bit more costly. (Finally, for specialized CPS things like its object repository, this means I have to expand local roles even more to be able to specify arbitray complex rules for who has what permission on an object (rules like "user foo has View, but if it's in group bar it doesn't, but if it's in group baz it has it nevertheless").) The visualization problem, while important, strikes me as secondary. But the question another poster asked, what does Zope 3 do about all this, is very important. It would be good to keep the same semantics. The difficult part is group+blocking. But I don't know enough about Zope 3 to answer these questions. Florent In article <16639.63903.938767.13160@gargle.gargle.HOWL> you write:

Local roles are "acquired" from ancestors.

While this is not bad for e.g. a "Manager" local role, its conceptual usefulness is in great doubt for e.g. the "Owner" role. It is very unclear why an "Owner" of a folder should automatically be an "Owner" of all its content.

I therefore propose to make "acquisition" of local roles customizable.

I see two potential variants:

1. objects get a boolean flag "__ac_acquire_local_roles__" with default value "True" which allows "acquisition" of all local roles.

2. objects get a dictionary "__ac_acquire_local_roles__" mapping role names to a boolean which allows acquisition for the respective role.

Of course, the second variant provides more fine grained control and will require a more complex UI.

The change would affect the methods "allowed" and "getRolesInContext". of "AccessControl.User.BasicUser" and would require new methods in "AccessControl.Role.RoleManager" to read and modify the new "__ac_acquire_local_roles__".

Moreover, I propose to change the local role management pages. When setting local roles, information about "acquired" local role definitions is very helpful. I therefore propose to display this information on the local role edit page.

I even would prefer a much more drastic change for both local role management and permission-role-map management: a compact look only overview mapping roles to users and permission to roles, respectively, with links to a page to edit the association of a single role or permission, respectively. Something like:

Role | acquire | locally assigned users| ancestor assigned users ------------------------------------------------------------------------- Owner | no | dieter | admin, dieter ------------------------------------------------------------------------- Manager | yes | dieter | admin -------------------------------------------------------------------------

The "Role" column is a link to a page to edit "acquire" and "locally assigned users" for the respective role.

Advantages:

* more natural behaviour for roles like "Owner"

* access restricted sub-sites would be much easier to implement

* more informative management pages

Risks:

* Classes deriving from "AccessControl.BasicUser" may have overridden "allowed" and "getRolesInContext".

Such overridden methods would not interpret "__ac_acquire_local_roles__" until adapted.

Fortunately, it is not very likely that these two methods are overridden.

* Local roles get a bit more complex.

However, explicit "acquisition" control is already used for the permission role mapping. Thus, users could recognize the same concept.

* The 2.8/2.9 edition of the Zope Book would need to be adapted.

If there is interest, I could implement the changes and provide patches against the Zope SVN version. However, I do not have write permissions to the repository. This means, someone else would need to make the actual checkins.

BTW: Almost surely, I will implement the proposed change in our "private" Zope copy and use it in one of our projects. This means, I could provide "production experience" for the change in some months.

-- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com