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