Hanno Schlichting wrote:
> Martin Aspeli wrote:
>> So, here is what I'd like to propose, ideally for Zope 2.12:
>> 1) Use an event handler to ensure that any <permission /> declared in
>> ZCML actually creates a valid, Zope 2 permission. I have working code
>> for this here which we could put in Products.Five with ease.
>> 2) Emit a warning instead of an error in Five's handler for the <class
>> /> directive when set_attributes or set_schema are used.
>> 3) Change the Permission class in AccessControl so that it tries to
>> look up an IPermission utility and use the title of that utility as the
>> permission name, falling back on the current behaviour of using the
>> passed permission name directly.
> I think we should start advertising the zope.security API for this
> instead. For example:
> from zope.security import checkPermission
> checkPermission('zope2.Private', context)
> This works by looking up the current security interaction from a thread
> local, which in Five's case is a FiveSecurityPolicy. This policy
> delegates to the checkPermission function found in
> Products.Five.security which does exactly what you want:
Oh, that's interesting. I had no idea that'd work.
That would indeed solve the inconsteincy for manual permission checks.
It would not help with any of the RoleManager APIs, though, e.g. how to
change permissions on an object.
It also wouldn't fix rolemap.xml in GS, MembershipTool.checkPermission
and similar, but we could fix those independently.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -