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

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.


 * more natural behaviour for roles like "Owner"

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

 * more informative management pages


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

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

Reply via email to