Managing permissions in KMKey
Permission management in Zope is so flexible that it's necessary to define a way of work to obtain good results. We want KMKey 3 to be able to have projects in any place in a tree of containers. And we also want people to access in many ways:
1. Someone could have access to the root of containers and to all of its children container and all of its projects
2. Someone could have access to just one of the containers and all its projects
3. Other people should access to just some projects in one container
4. Others should access some projects in different containers, and in different levels of the containers tree
How all these could be done ? Well, we will explain our way. We have an estructure workspaces / kmkey / subcontainers , where projects could be either in kmkey or in any subcontainer. All the roles playing are created as local roles in the portal root. And the permissions to each role are defined in the workspaces level. Then, all containers remains the acquire permissions attribute checked, and all the projects broke this acquire on the View permission. When this happens, the View permission is reassigned to all roles at project level, except the roles included in the portal property roles_without_acquire.
For instance, having roles WorkspaceReader and WorkspaceManager used in containers, and a role Reader used in projects (this could be defined in the project pattern), the previous examples could be solved that way (we include WorkspaceReader in the roles_without_acquire portal property):
1. The user is assigned to WorkspaceManager at kmkey level
2. The user is assigned to WorkspaceManager at subcontainer level
3. The user is assigned to WorkspaceReader at subcontainer level, and to Reader in all projects involved
4. The user is assigned to WorkspaceReader in its default subcontainer, and to Reader in all projects involved, despite to be out of its default container
This has a great avantage: we rely security on Zope, so no security holes will be included by KMKey.
But also has an important disadvantge: When the view permission is assigned to an existing role not having it, or a new role having this permission is created, all previous projects will not reflect that change, due to they aren't acquiring the View permission. So, in this cases, an upgrade process should propagate the changes to all affected projects, reindexing the affected portal_catalog indexes (allowedRolesAndUsers and localUsersWithRole)
We have discovered a better way to do the same that workarrounds that problem:
1. Use WorkspaceReader and WorkspaceMember at project containers levels
2. Use custom roles at project levels (Reader, Editor, etc ... never Member nor Manager, which have some magic)
3. Block roles using CPS -rolename feature. This could be done assigning to the group role:Anonymous the roles -WorkspaceManager and -WorkspaceMember. This will result in the same effect without breaking the acquisition of the View permission