On 11/1/07, David Jencks <email@example.com> wrote:
Alex wants the additional ability to call "CFO" a group and say it is
not a role and can't have any permissions directly assigned to it.
No this is not a correct representation.
BAD EXAMPLE WITH CFO: CFO is a bad choice since it's the Chief (single) financial
officer which can only be assigned to one user.
BETTER EXAMPLE WITH SalesRepresentative:
Let's say we have a SalesRepresentative role. Then I may create a group
completely separate from that role called a SalesRepresentativeS: note
capitalized last S to stress the presence of an extra S.
Then I would create a role_assignment with a reference to the
SalesRepresentative role, and a reference to the SalesRepresentativeS group.
This association now makes it so anyone added to the SalesRepresentativeS group
automatically gets assigned to the SalesRepresentative role. They now have
all the permissions in this role.
BACK TO CFO:
For the CFO I would simply not create a group at all. Instead I would just
make a role_assignment with a reference to some user and a reference to the
This allows me to easily conduct searches for assignments based on the role_assignment
objectClass to see immediately who is in the CFO role.
This makes the model weaker (groups have fewer
capabilities than roles) and more complex (there are more kinds of
things and relationships).
Dude roles and groups are not one and the same even if they can be modeled that way.