[Zope-dev] zope.localpermission and the "zope app permissions"

[Dan Korostelev]

2009/3/11 Martijn Faassen <faassen at startifact.com>:
> Dan Korostelev wrote:
>> Originally, I wanted to only move the "zope.Public" permission
>> declaration into zope.security, because that permission name is
>> special and always available. As for other permissions
>> (zope.View/zope.Security/zope.ManageContent, etc.), I wanted to just
>> leave them in zope.app.security as is.
>>
>> But security declarations for the "LocalPermission" class in
>> zope.localpermission needs the "zope.Security" permission. Also, some
>> of those permissions are used much in other zope.* packages for zcml
>> security declarations.
>>
>> So, I wonder what should we do with this.
>
> If it doesn't introduce new dependencies, I think a few more definitions
> of permissions in zope.security won't hurt (only those commonly used).
> I'd like that better than introducing a new package. Do you think this
> will be tolerable to you?

I also thought about this, but I decided that people will be against
that, because zope.security is intended to be really generic and only
permission it defines is the special "zope.Public" (there even was
discussions about renaming it to plain "public"). However, it's fine
with me, as long as we define them in a separate zcml file that can be
excluded and/or redefined for some special case.

> We should indeed only move those widely used.

That will require some research. When I'll be doing that, I'll post my
opinion on what permissions should go to "standard" ones and what to
deprecate and will call for comments and more information.

> The problem we have is that some content objects (i.e. not only the ZMI)
> declare that some of their methods need permissions. In order to support
> those we do need to have the definitions in a central place, and I think
> zope.security would be as good as any if we can do it without
> introducing more dependencies. Just put them in a separate submodule and
> we should be okay.

Yup, fine then. However, I think that there's no need for a submodule
when we can do that in simple separate zcml file. Or I miss something?


-- 
WBR, Dan Korostelev