aaroncohen73
commented
7 years ago I'm a bigger fan of solution 2 because it would make more sense for roles to be selected from a drop-down on a web interface than typed into a textbox. It also makes more sense to go with solution 2 because in the case that a role name needs to be changed it would allow for a single edit to be made to the role object instead of many edits having to be made to all of the user objects. It would be more initial work on the API specification and back end, but it would be easier to make usable on the front end.
MorganEPatch
A concept of a user's roles within an organization would be very useful for time reporting.
For instance, at the OSL, there are staff and student workers, whose time is billed at different rates. This distinction does not correspond to specific permissions/projects/activities, so a group permissions model relating to projects doesn't really help.
Currently this role is stored in the user's metadata field as an arbitrary string.
Possible solutions:
Create a new role-specific text field for the User object, which would contain a list of roles in some specified and validated format (comma separated list, probably). This is the simplest to implement, and allows arbitrary roles to be added on user edit without having to create additional objects. This doesn't enforce uniform role names or validate their entry (typos can become roles)
Create a object 'org_role' that can be associated with a user, similar to the time/activity relationship. In this scenario, org_roles would be added separately from users, and users would be assigned by selecting from available org_roles. This is a more complex solution, but allows restriction to a specific list of roles. Front-end software can query this list of roles to provide an easy filtering interface.