Charlie Clark wrote:
> Am 03.06.2009 um 13:05 schrieb Wichert Akkerman:
>> Not if you use collective.autopermission.
> In which it states:
> # This is borrowed from Products.CMFCore to avoid a dependency.
> Where it states
> # XXX This ought to be in AccessControl.SecurityInfo.
> :-/

That code is, but not the whole functionality. The functionality to 
register Zope 2 style permissions when a <permission /> ZCML statement 
is used is new to collectie.autopermission. I merged that back into Zope 
for Zope 2.12, so if you're on 2.12 you're in luck. :)

> It looks like I only need use_mailhost_services which I've hooked up  
> in like this
> security = ModuleSecurityInfo('Products.CMFCore.permissions') <-  
> should this reflect my module?
> security.declarePublic('UseMailHostServices')
> UseMailHostServices = Permissions.use_mailhost_services
> in a dedicated permissions module which I just include in the  
> configuration. Although I do like the event handling. Wouldn't it be  
> an idea to put this actually in the CMF?

The point is that Zope 2 permissions spring into existence when you 
start using them in a Module/ClassSecurityInfo. If nothing imports a 
module that has one of those, your permission doesn't exist. Prior to 
Zope 2.12, the <permission /> directive only used to map Zope 2 
permissions to IPermission utilities, but not actually create new ones.

> I also noticed that the CMF permissions are actually declared in Five.  
> Is there a reason for this? Surely the CMF permission declarations  
> should be in CMFCore

Sure. Historical reasons.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to