From: "Jeremy Hylton" <jeremy@zope.com>
LR> Well, currently Zope doesn't have any groups at all, so what the LR> Zope philosophy in that case is a bit fuzzy. :-) But yes, a LR> group would be a set ofprincipals.
Groups are a big help, and we can already use roles to implement "groups," so they exist in some sense.
Well, you can use roles as if they are groups, and that roles are Zopes name for groups are a common misconception.
(Is it possible to assign one role to another role? A SuperDeveloper had developer and super roles?)
No, and I don't think it should be possible either. A role consists of the permissions needed to perform the tasks you need in an organisational role. Making groups of roles would add an level of indirection that really has no purpose, and it will only make the user interface more complicated.
LR> But if groups do nothing more than group LR> principals, then groups are only a way to make assignments of LR> one principal to several roles quicker.
Quick has nothing to do with it. The hierarchy promotes modularity in security administration and makes it easier to reason about the policy.
Groups, as discussed so far, are only collection of principals, and are therefore only useful in making assignments of one principal to several local roles quicker. There are several ways of implementing hierachies, and if they promote modularity and makes it easier to reason about a policy depends in part on how that implementation is done. If hierarchies are introduced I think the most useful way would be by creating a user hierarchy with organisational units in which users are placed, a la NDS. It would be misleading to call these organisational units "groups". Hierarchy can be useful, but what is also useful is orthogonality, which you don't get with groups. With "workgroups" you do.
I'm not sure what the innovate roles concept is :-).
Thats interesting, since you have been discussing it. :-)