Start permissions overhaul: Define user role permissions in the database

[wrongecho]

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.

• user_role_admin_settings_access - Access to the Admin/Settings pages
• user_role_clientmgmt_access - General client & contact management
• user_role_ticketing_access - Ticketing
• user_role_credential_access - Access to credentials/logins/passwords
• user_role_sales_access - Selling (e.g. quotes, invoices, etc)
• user_role_finance_access - Accounting/Finance (payments, transfers, etc)
• user_role_reporting_access - Access to the reports pages (both financial and technical)
• user_role_other_access - Catch-all for anything else, reserved for future use

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.

• 0 - No access
• 1 - Read
• 2 - Write (Read/Write/Archive)
• 3 - Full (Read/Write/Archive/Delete)

---

Related:

• Feature Request: Permissions system overhaul / Enhance role enforcement for all pages #530
• https://forum.itflow.org/d/50-user-permissions/7

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
41.0% Duplication on New Code

See analysis details on SonarCloud

[wrongecho]

Test these changes at: https://userroles1008.pr-review.itflow.org
(automatic message)

[wrongecho]

Test these changes at: https://userroles1008.pr-review.itflow.org
(automatic message)

[johnnyq]

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

[wrongecho]

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?