Roles and permissions
Four roles, one per account. The tables below are generated from the same seed file the installer applies, so they are what your installation actually enforces.
The four roles
| Role in the interface | Role identifier | Holds |
|---|---|---|
| Admin | system_admin | Every permission below |
| Manager | operator | 12 of 38 permissions |
| Verifier | verifier | 4 of 38 permissions |
| Viewer | viewer | 3 of 38 permissions |
Permission by role
| Permission | Identifier | Admin | Manager | Verifier | Viewer |
|---|---|---|---|---|---|
| View users | users.view | Yes | |||
| Create users | users.create | Yes | |||
| Update users | users.update | Yes | |||
| Disable users | users.disable | Yes | |||
| Reset 2FA | users.reset_2fa | Yes | |||
| Create verifiers | verifiers.create | Yes | |||
| Update verifiers | verifiers.update | Yes | |||
| Disable verifiers | verifiers.disable | Yes | |||
| Manage roles | roles.manage | Yes | |||
| Manage permissions | permissions.manage | Yes | |||
| View courses | courses.view | Yes | Yes | Yes | |
| Create courses | courses.create | Yes | |||
| Update courses | courses.update | Yes | |||
| Archive courses | courses.archive | Yes | |||
| View participants | participants.view | Yes | Yes | ||
| Create participants | participants.create | Yes | Yes | ||
| Update participants | participants.update | Yes | Yes | ||
| View certificates | certificates.view | Yes | Yes | Yes | Yes |
| Create certificates | certificates.create | Yes | Yes | ||
| Update certificates | certificates.update | Yes | Yes | ||
| Submit certificates | certificates.submit | Yes | |||
| Assign certificates | certificates.assign | Yes | Yes | ||
| Verify certificates | certificates.verify | Yes | Yes | ||
| Return certificates | certificates.return | Yes | Yes | ||
| Reject certificates | certificates.reject | Yes | Yes | ||
| Revoke certificates | certificates.revoke | Yes | |||
| Export certificates | certificates.export | Yes | Yes | ||
| Download certificate PDFs | certificates.download_pdf | Yes | |||
| Generate certificate documents | certificates.issue | Yes | Yes | ||
| Archive certificates | certificates.archive | Yes | |||
| Restore archived certificates | certificates.restore | Yes | |||
| Soft-delete eligible certificates | certificates.delete | Yes | |||
| Create imports | imports.create | Yes | Yes | ||
| View imports | imports.view | Yes | Yes | ||
| View reports | reports.view | Yes | |||
| View audit logs | audit.view | Yes | Yes | ||
| View email queue | email_queue.view | Yes | |||
| Manage settings | settings.manage | Yes |
Rules that are not in the table
Permissions decide what an account may do. Four rules decide who may hold them, and they are enforced on the server, not by hiding buttons.
- The administration area is closed to verifiers. Every address under
/adminrequires the Admin, Manager or Viewer role in addition to the permission. A verifier'scertificates.viewpermission therefore cannot open the global certificate register. - A verifier sees only its own assignments. Ownership is checked when the record is loaded, so changing the number in the address bar returns 403 rather than another organisation's certificate.
- Nobody changes their own role, and an existing Admin cannot be edited by another Admin. A Manager, Verifier or Viewer can be promoted to Admin; that is a one-way door.
- A role change takes effect immediately. Active sessions for that account are revoked, the change is written to the audit log with the previous and new value, and an account entering the Verifier role must activate again and pair an authenticator.
Read-only review
A Viewer can inspect active certificate records, course and occurrence lists, template metadata and the append-only system log. It cannot create, edit, delete, assign or verify business records, import/export certificates, generate PDFs or open configuration screens. Its own account profile and sign-in security remain available. Record access is separate from the protected edit screen; changing the address to an edit or write route is denied.
Creating accounts
- Sign in as an Admin and open Users.
- Choose Create user, enter the name, email address and role.
- The account receives an activation link valid for 24 hours. Nothing is usable until the person follows it, sets a password and pairs an authenticator.
- If the link expires, use Resend activation on the same screen.
Verifier accounts belong to an organisation, and that organisation name is what the public certificate page shows as the approving body. Set it when you create the account.
Two-factor authentication is not optional for internal accounts. An account that requires it and has not paired an authenticator yet is offered the QR code at its first sign-in, and cannot get past that screen without a working code. Recovery codes are shown once, at pairing.
Disabling an account
Use Disable rather than deleting. Disabling revokes every active session at once, keeps the audit trail intact, and leaves the certificates that account issued untouched. A disabled verifier cannot be assigned new certificates, and any certificate already assigned to it has to be reassigned by a Manager.