In Zope 2 prior to Zope 2.12, registering a new permission involved the
following (usually behind-the-scenes) steps:
1. adding the permission name to the
AccessControl.Permission._registeredPermissions dictionary
2. adding a tuple to the Products.__ac_permissions__ list including the
permission name and default roles
3. setting a attribute (with name equal to a mangled version of the
permission name) of
AccessControl.Permission.ApplicationDefaultPermissions to the default roles
4. registering the permission as a Zope 3 permission using the
<permission> ZCML directive
In practice in CMF-based applications, the first 3 items of this list
were often accomplished by a call (usually during product
initialization) to Products.CMFCore.permissions.setDefaultRoles. So for
a developer adding a new permission, there were generally 2 tasks
required (calling setDefaultRoles and calling the <permission> directive).

In Zope 2.12, the situation improved.  There is now an event handler
which automatically performs steps #1-3 when a permission is registered
using the <permission> directive, setting the default role to Manager.

Unfortunately, this makes things tricky if one wants to register a
permission with a different set of default roles. That's because
setDefaultRoles (and its new incarnation as
AccessControl.Permission.addPermission in Zope 2.13) abort if you try to
register a permission that is already registered, so it needs to be
called prior to the execution of ZCML actions -- so import time is the
only option.


As an alternative to requiring calling setDefaultRoles/addPermission at
import time, I suggest that we add an optional roles attribute to the
<permission> directive.  This would then be used when the directive is
executed, instead of the current hard-coded Manager setting.  Examples:

<!-- a new permission with 2 default roles -->
<permission id="my.NewPermission" title="My new permission"
roles="Manager SiteAdmin"/>
<!-- a new permission with Manager as the sole, implicit role
(backwards-compatible) -->
<permission id="my.OtherPermission" title="My other permission"/>

Thoughts? One downside is that we would need to override the permission
directive instead of using the implementation in On the
other hand, it's not a complicated directive.

thanks for your consideration,
David Glick
 Web Developer

Groundwire: You Are Connected             
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to