[Zope3-dev] Re: a note on groups and roles

[Chris McDonough]

> No, it's not. Groups are collections of principals, roles are collections
> of permissions. Both make are an indirect way of mapping principals to
> permissions, but we can't equate them in this discussion, because then
> most of the points of the discussion disappear. :-)

Dont you think this is kinda complicated?  What practical purpose does being
able to map permissions to users in two different ways really serve?  What
practical goal is being serviced?  The Microsoft guy also says that groups
*are* principals.  I'm really confused.  Help!

I very much appreciated your writeup of the Zope 3 security stuff attached
to your workgroup propsal, I'm going to reread it.

> That is not a bad idea. But it doesn't really diminish the use of
> collecting permissions into roles, because there is still a huge set
> of roles.

Maybe, I dunno.  Actually, Zope ships with only one "true" role, "Manager"
(the others are pretty silly).  Most apps define three or four more.  If
roles/groups are really placeful, you only need to see the ones you're
interested in by visiting the place in which they're defined.  Can you
provide a set of circumstances would cause you to need a huge set of roles?

> As I understand your suggestion, you, instead of defining roles that have
> a set of permissions and then adding users to these roles, you want to
> define groups with a set of users, and add permissions to these groups.

I want to be able to grant a set of permissions to a group of users.
Whether that group of users is called a role or a group is not that
meaningful of a distinction to me. ;-)  I understand that there is some
defacto jargon centered around roles as collections of permissions and
groups as collections of users and that this jargon is starting to gel.  I
just want to raise a red flag at this point to say that I don't understand
why it needs to be this complicated, seeing as we're essentially starting
from scratch and no other system that I can think of has this particular
combination of (extensible) collections.

> However, the discussions and requests for groups so far have been founded
> in the need for another level of indirection in the user to permissions
> mapping. Your suggestion doesn't solve that. You just replace roles with
> groups. There is no real simplification, and there is no additional
> features.

Whoo hoo!  I like "no new features"! We need to understand the old ones
first. ;-)

I'm not sure why my suggestion doesn't solve the problem you mention.  The
indirection in my suggestion happens as a result of being able to nest
groups, which you currently cannot do with roles right now.  This inability
drives normal people insane because they need to do the same thing over and
over again in different places.  This is why everybody is crying for another
layer of indirection.  They need to shoehorn it in to the current Zope 2
model, so they are thinking in terms of roles, but it doesn't need to be
this way. ;-)

Example: you define a group at the root.  You assign a set of users to the
group.  You visit a folder and create another group, which includes a
"local" set of users as well as the group you defined at the root.

Can you give an example of a problem that this sort of thing doesn't solve?

> Yeah, the Owner role is easily confused with actually being an owner. Is
> there any reason it can't be dropped? Shouldn't "Can own objects" rather
> be a permission?

The global owner role is... absurd.  I dont know why it's there.


---

Note that I'm bitching about all this stuff partly because it's likely that
I'll need to write the docs for whatever security stuff happens in Zope3,
I'm essentially very lazy, and I found it difficult to document the current
Zope 2 security system in the Dev Guide (which we're *adding to* but not
*subtracting from* in Zope 3), and I prayed for Amos' and Michel's souls
when they wrote about security in the Zope Book.  But this doesn't
necessarily make me wrong.  Yet.  ;-)