Hey, people! The refactoring of zope.app.security is now almost done. There's still some polishing work to do and two little issues to resolve. One of them is the zope's "common permissions". Most of zope.* and zope.app.* (and other) packages define some security protections for their classes and views using common permission names defined in zope.app.security. We decided to move those permission definitions to a separate and excludable/overridable zcml file to zope.security, so packages that use them would't need to install anything additional. But we want only generic and useful permissions to be a part of "common set", so we need to select ones from zope.app.security. Currently, zope.app.security defines these permissions (not counting zope.Public, that already migrated to zope.security): - zope.View - zope.Security - zope.ManageContent - zope.ManageBindings - zope.ManageCode - zope.ManageServices - zope.ManageSite - zope.ManagePrincipals - zope.ManageApplication Permissions, that needs to be in a common set (IMHO), mostly because it's used by current zope.* packages: - zope.View - zope.ManageContent - zope.Security - zope.ManageServices - zope.ManageSite To be honest, I don't quite get the difference between zope.ManageSite and zope.ManageServices. Can someone clear this point for me? May be they should be merged somehow. Permissions that can stay in zope.app.security, and reasons: - zope.ManageBindings - What's that? I can't find any usage of it. - zope.ManagePrincipals - That looks like it was intended for something like zope.app.authentication, but zope.ManageServices is used there instead. - zope.ManageCode - I guess it's intended for TTW development that's not used/developed much and even discouraged now-a-days? If so, I believe that it can stay in zope.app.security. - zope.ManageApplication - Looks like it's intended for and used mostly in "zope.app.applicationcontrol" which has more to do with "zope3, the application server", than the "zope.framework". -- WBR, Dan Korostelev