[Zope3-dev] a note on groups and roles

[Matt Behrens]

On Sun, Mar 24, 2002 at 02:15:21PM +0100, Lennart Regebro wrote:

> From: "Matt Behrens" <matt@zigg.com>

> > We have a workflow application I'm hopefully deploying soon, and
> > the first thing it's going to cover is development requests.  Here
> > we have a couple roles: Development Manager, Application Administrator.
> > In one of the systems we take development requests for, these are
> > useful and necessary, but on the other system, the development
> > manager *is* the administrator, and it makes perfect sense to make
> > another role to encapsulate them.

> What does this mean: "the development manager *is* the administrator"?

It means that, by virtue of how the system they're developing for
runs, the development manager performs the administrator's duties
as well.  Sure, you *could* just go assign the principals in question
both roles, but shouldn't the option be there to not?

If everything is a group, this is not even an issue.

> It's possible to let roles be a part of other roles, but it breaks the
> structure of roles being a set of permissions and it would make the user
> interface more complicated.

Is that really such a useful dichotomy?  No matter what you do, the
defalt UI is still going to need to be rethought, seriously.  In
addition, as Chris Humphries was pointing out to me on IRC, it's
only the default UI -- in Z3, you could download or create one of
any number of ways to administer security!

Perhaps in a folder's security view, we see only the groups that
are defined on or near that folder, and can give those groups
permissions.  That's really what we call 'roles' without actually
needing to *be* roles.  One could then click on a group and associate
it with groups defined higher on up the hierarchy.

> Everybody seem to agree that there should be
> some sort of user groups, the disagreement is just what kind, and if roles
> should be removed or not.

Most certainly.  I think the Z2 concept or a 'role' is useful,
definitely, but since I've been dwelling on Jeremy's words, I don't
see why there's any point to making them different types of objects
(or whatever you call things that implement two different interfaces,
if someone could get me the correct terminology I'll sound less
moronic.)

> Grouping roles are another complication, and I
> don't understand the use.

But I do :-)