|Version 4 (modified by trac, 8 years ago) (diff)|
Real relational role/group support
Trac's data model subsumes groups into permissions within an implicit distinction through case. This makes finding permissions are groups unnecessarily complicated and error prone.
I use the term roles for clarity as group is a key word in SQL and subsequently in a lot of code.
There is a RelationalPermissionsStore and a RelationalGroupsProvider in perm.py and PermissionCache has been extended to support req.perm.roles
My patch implements tables for user_role, roles and role_role:
create table user_role (username text, role text, UNIQUE (username, role)); create table role (name text, description text,UNIQUE (name)); create table role_role (role text, parent text, UNIQUE (role, parent));
Patches have been applied to
- ticket/model.py, and
report.py supports the $ROLES keyword but expects parameters to be passed in to the cursor rather than quote the statement, ie. sql_sub_vars has become obsolete. This is similar to the way in which query.py and model.py work and it would make sense to harmonise this.
report.py requires explicit support for roles in the various reports. The others are restricted by default by the JOIN on user_role so that only members of the same group can see each other's tickets.
It works like this. Users belong to at least one of the following groups: authenticated, beta or developer and these groups can be hierarchical. Users can only see reports or tickets that have been submitted by a member of the group to which they belong. ie. if you belong to 'authenticated' you can only see tickets submitted by members of that group; if you belong to 'beta' you can see 'beta' and 'authenticated' but not 'developer' tickets; if you belong to 'developer' you can see all tickets. This makes more sense to me than declaring particular tickets private which take more work to implement. I have adpated all scripts responsible for displaying tickets - it's unfortunately more complicated than it should. If you want to restrict access to tickets you do this by the way members belong to groups.
If you have any issues, create a new ticket.
You can check out the source for RelationalRoleSupportPatch from Subversion at http://trac-hacks.org/svn/relationalrolesupportpatch.
req.perm.roles returns a list of permission
pass this into queries as tuple so and use WHERE role in %s to execute