Admin Permissions
The Circular Wave system is in the process of transitioning from the Legacy (v1) permissions to the new Flexible permissions system (v2). Both systems are described below.
Currently:
- Payment runs use v2 permissions.
- Timesheets use v1 permissions in all orgs/collabs other than CDDFT, where they use a precursor to v2 permissions.
- Everything else uses v1 permissions.
Work on porting code (mostly backend) to use the new v2 permissions is scheduled to begin once the UI for managing v2 permissions has been completed.
Legacy (v1) Permissions
Overview
Legacy (v1) permissions are based on three separate lists of permissions:
- General permissions (see below for available permissions)
- Site permissions (a subset of sites in the collab - stored in the table)
- Services permissions (a subset of services in the collab - stored in the table)
The general permissions control whether an admin has access to a given feature or not. For example, if they have the reporting permission then they will have access to the reporting feature.
Most permissions apply globally to the entire org/collab with no scoping. However, for shift permissions the site and service permissions restrict the admin to viewing and manipulating and creating shifts that are at sites and in services that they have access to.
Database tables
| Table | Purpose | Columns |
|---|---|---|
users.admin_permissions |
General permissions | admin_key, key, enabled |
users.admin_sites |
Enabled sites | admin_key, site_key |
users.admin_services |
Enabled services | admin_key, service_key |
Legacy General Permissions
The following general permissions are available (these are the values for the key column in the admin_permissions table. For a given admin they can either be enabled or disabled.
| Category | Permission Key | Description |
|---|---|---|
| Staff / Candidates | bankCanInvite |
|
| Staff / Candidates | bankCanSuspend |
|
| Staff / Candidates | bankCanView |
|
| Staff / Candidates | bankCanViewRemoved |
|
| Staff / Candidates | bankCanRemove |
|
| Staff / Candidates | bankCanEditOrgSpecificMetadata |
|
| Staff / Candidates | bankCaneditRGS |
|
| Staff / Candidates | bankCanEditBasicDetails |
|
| Compliance | complianceCanApproveAndReject |
|
| Compliance | complianceCanApprove |
|
| Compliance | complianceCanReject |
|
| Compliance | complianceCanViewDetails |
|
| Shifts | bankCanRelease |
|
| Shifts | bankCanRetract |
|
| Shifts | jobsCanBook |
|
| Shifts | jobsCanCreate |
|
| Shifts | jobsCanDeleteJobs |
|
| Shifts | jobsCanEditSlots |
|
| Shift Agencies | vmsCanApproveAgencyRequests |
|
| Shift Agencies | vmsCanBookAgencyCandidate |
|
| Shift Agencies | vmsCanSendAgencyRequests |
|
| Shift Agencies | vmsCanViewAgencyRequests |
|
| Shift Agencies | vmsCanSubmitAgencyCandidates |
|
| Timesheets | timesheetsCanApprove |
|
| Timesheets | timesheetsCanReject |
|
| Timesheets | timesheetsCanView |
|
| Timesheets | timesheetsCanManageLockedTimesheets |
|
| Payment Runs | payRunCanManage |
|
| Payment Runs | payRunCanView |
|
| Reporting | reportingCanView |
|
| Admins | usersCanEditPermissions |
|
| Admins | usersCanEditSitePermissions |
|
| Admins | usersCanManageHiddenPermissions |
|
| Admins | usersCanInvite |
|
| Admins | usersCanView |
|
| Admins | servicesCanManage |
|
| Sites | sitesCanCreate |
|
| Sites | sitesCanEditDetails |
|
| Agencies | vmsCanManage |
|
| UNUSED | orgCanEditDetails |
|
| UNUSED | orgCanEditPolicies |
|
| UNUSED | orgCanViewPolicies |
|
| UNUSED | rateCardCanOverride |
|
| UNUSED | sitesCanEditPolicies |
|
| UNUSED | sitesCanViewPolicies |
Flexible (v2) Permissions
There are some global permissions in the Flexible (v2) permissions model too, but many permissions in the v2 model are scoped:
- Permissions related to staff or compliance are scoped by Staff Bank
- Permissions related to shifts are scoped by Shift Group
- Permissions related to payment runs are scoped by Payment Run Type
- Some permissions related to admin management are scoped by Admin Group
Additionally the v2 model introduces the notion of "admin groups":
- Admins can be members of admin groups (many-to-many relationship)
- Admin groups can be granted permissions
- Admins inherit the permissions of groups they are members of (permissions are additive)