We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 5111 - refactor flexible roles to a new design
refactor flexible roles to a new design
Status: RESOLVED FIXED
Product: OMP
Classification: Unclassified
Component: Framework
1.0
All All
: P5 enhancement
Assigned To: PKP Support
Depends on:
Blocks: 4971 4987
  Show dependency treegraph
 
Reported: 2010-01-27 16:53 PST by Juan Pablo Alperin
Modified: 2010-04-09 18:01 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Juan Pablo Alperin 2010-01-27 16:53:21 PST
: USER
: 1 Juan
: 2 Florian
: USER_USER_GROUP
: user:1 user-group:1
: user:2 user-group:2
: USER_GROUP
: 1 "Editors" role:1 seq:1 path:editor press:1
: 2 "Designer" role:1 seq:2 path:designer press:1
: USER_GROUP_SETTINGS
: group_id
: locale
: setting_name
: setting_value


upgrade script:
: 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
Comment 1 jerico 2010-03-28 07:59:38 PDT
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.