I'm trying to determine if the built-in RACL (role-base access control list) functionality using groups and permissions tables is right for me.
My requirements are: 1) A user is an administrator of one, several, or all accounts (in account table), with varying levels of administrative rights. 2) An account contains one or more locations (in location table) 3) A user has varying levels of rights to administer one, several, or all locations. 4) Given a user, the application will determine all of a person's permissions. 5) The application will, of course, enforce permissions as user tries to read/write settings. Using groups to represent each resource will not work, because the table which contains the user field is not the table which defines the role. That is, if I want to know all accounts the user can administer, then I need to query all auth_group rows to determine all accounts, and then join with auth_membership table to see which groups user is a member of. That is a not a reasonable solution, so I'm left with adding permissions to the user_<userid> group for each resource. But there are still numerous problems: 1) more complex query logic to retrieve user permissions in tables separate from auth_user table 2) if a user has rights to administer all resources of one type, then permissions need to be added to all records of that type. and each time a new record is added or deleted, permissions need to be synced with all users who have permissions to all records. also, if a resource moves between locations, location-specific administrators will need their permissions synced as well. 3) the permissions do not specify more custom restrictions on particular fields in the table or what the user can do with those fields. It seems to me that I'm best of with managing a user's permission directly in the auth_user table, by adding fields such as: - allowAllLocations - allowLocations: list:string Does anybody have another suggestion? thx
