PKP Bugzilla – Bug 5111
refactor flexible roles to a new design
Last modified: 2010-04-09 18:01:31 PDT
: 1 Juan
: 2 Florian
: user:1 user-group:1
: user:2 user-group:2
: 1 "Editors" role:1 seq:1 path:editor press:1
: 2 "Designer" role:1 seq:2 path:designer press:1
: ROLES will be renamed to USER_USER_GROUP
: in ROLES rename role_id to user_group_id
: move press_id from ROLES to USER_GROUP
Please see the wiki page <http://pkp.sfu.ca/wiki/index.php/Authorization_Framework> for a more complete discussion of the entities involved.
> - in the USER_GROUP table, why do we have the name listed there?
> Shouldn't the name go into the settings table?
Yes, it probably should, so that it can be translated.
> - in the USER_GROUP table, what was the purpose of the role column? To
> store the role_id constant that is currently hardcoded in the Roles class?
Exactly. It represents the foreign key to the imaginary "role" entity that is hard coded into the application. It fulfills the same function as the "role_id" column in the current "roles" table that will be deleted.
The attribute should be called role_id, though, and not role so that it becomes conceptually clear that this is a foreign key. The same is true for the user and user-group columns in the other tables, of course.
> - why did we opt to keep the path column? If we're keeping the
> hardcoded role constants, wouldn't the mapping to a URL path be the same
> as it is currently?
When we discussed the change it was a potential requirement that every user group had its own "personalized" user page and that this is also represented by individual URLs that replace the role name with the user group name.
What is also missing in the above sketch is the fact that the user group with the lowest sequence number will never be deleted.
new classes and database structure:
changes to various parts of application
changes to listbuilders