[Zope-dev] Roles, groups and permissions: Less talk, more action! :-)

Lennart Regebro lennart@torped.se
Mon, 25 Mar 2002 00:37:14 +0100


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.