Roles, groups and permissions: Less talk, more action! :-)
Since I'm not good at explaining how I think Zopes groups and roles should work, I have decided to show you instead: The patch is availible at http://www.zope.org/Members/regebro/workgroups/ . Just zip it up in the Products directory and restart. I won't be held responsible for anything even if it definitely is my fault. :-) This is a "proof of concept" implementation. It's availiable as a "monkeypatch" that should work on both 2.4 and 2.5 and maybe even 2.3 and 2.2. The user interface is ugly, and the code is uglier, but who cares. This is a fast hack to show how I think it should work instead of trying to explain it. :-) So, please: Check this out and say what you think. I think this a definite improvement. Another definite improvement should be switching the permissions and local roles pages. The roles should pop up first, and the permissions page could be access from that one. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB
Ok, this matches what I expected. Here's some nitpicking :) - I really don't like the term groups or workgroups for what you have, because I see them as mappings between two kinds of concepts (the users and the roles) whereas groups implies only one kind of thing. - For the Blacklist part, I'd like to propose slightly different semantics with respect to the white and black lists. Basically I'd like them to be exclusive: if someone is on the whitelist he cannot be on the blacklist, and vice versa. This cleans up some behavior of the UI that the user would find nonintuitive. (However see my comment below, with groups we can't do that.) The other thing we will have to resolve (and it's also true for Zope 3 anyway) is how user groups will interact with the blocking that blacklists provide. Is the blacklist evaluated first, or is it the whitelist ? For instance, suppose I have a user group G1=(U1,U2,U3), and G2=(U1,U2). Suppose G1 is in the whitelist and G2 in the blacklist. In a system where we can grant or deny permissions to things that are groups, we'd ideally want to be able to say "allow G1 except (G2 except G3)" which cannot be decomposed in a disjoint set of "allow those " and "deny those". Hope I'm clear :) Florent Lennart Regebro <lennart@torped.se> wrote:
Since I'm not good at explaining how I think Zopes groups and roles should work, I have decided to show you instead:
The patch is availible at http://www.zope.org/Members/regebro/workgroups/ . Just zip it up in the Products directory and restart. I won't be held responsible for anything even if it definitely is my fault. :-)
This is a "proof of concept" implementation. It's availiable as a "monkeypatch" that should work on both 2.4 and 2.5 and maybe even 2.3 and 2.2. The user interface is ugly, and the code is uglier, but who cares. This is a fast hack to show how I think it should work instead of trying to explain it. :-)
So, please: Check this out and say what you think. I think this a definite improvement. Another definite improvement should be switching the permissions and local roles pages. The roles should pop up first, and the permissions page could be access from that one. -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
From: "Florent Guillaume" <fg@nuxeo.com>
- I really don't like the term groups or workgroups for what you have, because I see them as mappings between two kinds of concepts (the users and the roles) whereas groups implies only one kind of thing.
Well, they are collections of user, and hence they are what groups are usually ment to be. They do have the additional information of giving the users roles. If somebody can come up with a better name, that's not a problem for me. Teams? Departments? Grüpps? Roled principal collections? :-) In any case, I think it would be a good idea to have the word "group" somewhere in the user interface. It is obvious that people when looking at the access control in Zope are actively looking for the groups. Today they find roles, and mistake them for groups, causing much confusion. :-)
- For the Blacklist part, I'd like to propose slightly different semantics with respect to the white and black lists. Basically I'd like them to be exclusive: if someone is on the whitelist he cannot be on the blacklist, and vice versa. This cleans up some behavior of the UI that the user would find nonintuitive.
Maybe, I'll disuss it with Johan, and we'll see. The user interface as it stands is more or less ad hoc.
The other thing we will have to resolve (and it's also true for Zope 3 anyway) is how user groups will interact with the blocking that blacklists provide. Is the blacklist evaluated first, or is it the whitelist ?
Yup. As it is now the blacklist blocks out roles gotten from local roles or via group assignments, but not global roles. Which way it should be is definitly a matter for discussion. It would also be possible to have unissigned blacklists, that blocks a role for all users. In that case it could be useful to let group roles override a blocklist. There are endless possibilities for detailed design changes. Ideas and thoughts are most welcome. And in true XP fashion, the ideas with the most use and least cost (in this case I'd define cost as making things complicated to use) will be implemented first. Having an easy UI while having a high flexibility is always hard.
participants (2)
-
Florent Guillaume -
Lennart Regebro