>>
>>>>The purpose of the UserRights table is not clear to me. Do you intend that users should be given rights without being assigned to >>any roles?
>>
>>
>>Rights are assigned first to roles, Then a user is assigned one or more roles. Then any user right that is different than the role right is
>>stored in UserRights.
>>
>>So after login the rights for the user's roles are loaded, then the UserRights are loaded on top of them.
>
>Understood. But my gut feeling is that it will be too complicated for an end user (acting in an 'Admin' role) to get a clear picture of exactly *why* which rights are available to each user (the same problem exists on a lesser scale as soon as you allow users to be assigned to more than one role). Why not just create an additional role to handle the 'fine-tuning' and drop the UserRights table?
>
>>
>>>>Why are the password details in the UserRoles table rather than the Users table?
>>Because a user logs in as a specific role. His/her rights would be determined by the role they log into.
>
>Don't see this. Why allow a user to login in different ways to obtain different rights - why not simply require them to login as a different user?
>
>>
>>>>How do the RoleRights.AccessLevel and Rights.AllowDeny fit together?
>>
>>The table has been changed 'AccessLevel' should read 'AllowDeny'.
>
>OK. So is the AllowDeny field needed in the Rights table?
>
>Going back to my first comment above: I haven't really found a way, even with my simpler structure, of presenting a clear picture of exactly why a specific user is assigned a specific right. Any thoughts on this?
>Regards,
>Viv

I guess I was thinking that someone might be a member of different groups at a workplace. I was trying to make it generic, but I may
have gone overboard.