Hi David, I'm going to start condensing a bit by removing points we agree on again.
On 10/31/07, David Jencks <[EMAIL PROTECTED]> wrote: ... > that we agree on the role-permission side of roles :-) > Yes but not on putting users into roles. ... I don't think so. In my thinking a role or permission is globally unique, > for instance if we are using ldap its "full name" might be its dn. So far I > can't imagine any use except increasing confusion for any concept of > redefining. I'll listen if you have some ideas :-) > We both agree on (really like) this idea of using scopes with visibility rules. Perhaps in a little bit we can add more clarification to this concept and better define the scoping rules that govern it. ... > #2 is about Role assignment and does not belong in the definition of a > Role. > Roles are independent of users and groups. > > > I'm not convinced. If roles are associated to either users or groups, we > can talk about the association at either end: either at the role end or the > [user|group] end. > Well my aim was not to take any particular side by defining an entity in our model called a role_assignment. The role_assignment does the association and then direction does not matter. Similarly we could talk about the role-permission association at either the > role end or the permission end. If you don't like this I'm going to request > that we describe all the associations as separate entities so there is no > bias about which way the association points. > Great this is what I've been doing all along with role assignments. role-assignment objects contain the associations of users to roles. This way roles are purely defined as a set of references to permissions. That's an implementation detail. > Not really we're still dealing with an abstract model. Furthermore it's a matter of being impartial. ... Alex
