#16: Local roles blacklisting

The current local-roles implementation in Zope makes it impossible to reduce the rights given to users
when you go deeper in folder hierarchy since roles, once given to a user, cannot be taken away from a user. Therefore it is impossible to have a really flexible and moreover easy-to-use way of dealing with security. An ideal situation would be that you are able to provide access to your site-root to everybody by giving the whole group the proper role and when you go deeper in the structure, you start restricting access by redefining the local-roles in that context. Right now, you can't really do that without using tricks with workflows and even then it is very limited and very confusing and counter-intuitive.

Even when PLIP7 is fully functional, you still can't restrict access to certain folders inside GroupFolders for users that have access to the GroupFolder itself. You can think: why would you do that? Well, there are numerous situations where you want this. Of course you can define a workflow-state that give permissions to certain roles but once you have given a user this role and you want to further restrict his access to subfolders, the only thing you can do is to create a new role and a new workflow-state, a new role that the user doesn't have already. But this only postpones the problem to a folder level deeper. This PLIP describes the solution and would make live a lot easier.

The proposol for this PLIP is to enhance the way GRUF checks for local-roles in such a way that before it traverses up
the folder hierarchy, it checks if the current folder is set to acquire local-roles from parents or not. This check is done for every parent it finds on its way up the tree.

Implementing looks quite simpel and I have done some tests that have been very promising. At first, in the Sharing page
in Plone a check-box is added where the user with proper permissions can check if he wants to acquire the local-roles from parent folders or not. The selection is then stored as a property on the folder/object.

The next step would be to alter the function in GRUF that returns the local-roles in a given context. As far as I can see this happens in GRUFUser.py in the function getRolesInContext. Inside that function is a simple loop that does the traversal. In this loop a check needs to be done on the current object to see if it has set the property for acquisition or not. If set to false, the loop will stop.

As I said, I did some tests and it seemed to work. I did encounter a problem that I couldn't fix and it seemed at that time only remotely related to this but I'm not sure exactly what this problem was back then (sorry). I expect that when enough skilled people take a look at this, this can be fixed. And like I said, the idea is simple but the implications are huge and could make our lives sooo much easier.