Closed wrongecho closed 2 weeks ago
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
41.0% Duplication on New Code
Test these changes at: https://userroles1008.pr-review.itflow.org
(automatic message)
Test these changes at: https://userroles1008.pr-review.itflow.org
(automatic message)
I love it @wrongecho and it got me thinking for further extensibility of the permission by taking your single table ideas and merging them into multiple relational tables like so
users user_id user_role_id
user_roles user_role_id user_role_name user_role_description user_role_is_admin (1 or 0) of 1 then access to everything so there is no need to define an actual admin role)
modules module_id module_name (Example module_ticket, module_sales) module_description
user_role_permissions user_role_id module_id permission_level (1 Read (Read), 2 Write (Read, Edit, Archive) / 3 Full (Read Edit Archive Delete) If no row exists then no access is given
Admin will be a defined role but won't need tables rows under user permission as they will automatically have full access
Totally on board with it being more modular.
I think we could then replicate user_roles into api_roles and user_role_permissions into api_role_permissions to allow more granular management of API permissions?
This PR creates the database schema required to start defining user roles/permissions via the database. For now all we're doing is adding the fields, they don't actually do anything yet but they will soon.
Once we've got this in place, we can start to add logic on pages to check permissions against the DB rather than directly in the code. This will allow us to be able to offer custom user roles with custom permissions (maybe you want your more senior tech to have full access to client management & the business finances, but not your junior tech).
Very keen to hear your thoughts :)
Module access
Similar to the matrix we've manually defined across the app, but with a few more categories for flexibility.
Access levels
I really like the concept of destructive deletes being off by default. Now that archiving/unarchiving is properly implemented in most of the app, I think it's safe to say that 'Write' access can include the ability to archive something. This at least allows a user to partially undo something they added by mistake using their Write access.
Related: