On 11/1/07, David Jencks <[EMAIL PROTECTED]> 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 CFO role. 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. Alex
