How permissions work
- Checked on the server, on every request. The web application hides what you cannot use, but that is a convenience.
GET /api/mereturns the permissions in effect for you. - Exact. A check names one key, and no key implies another. Holding
admin.managealone does not let you dispatch, andcad.dispatchis no use withoutcad.view. - From roles. An administrator gives a staff member one or more roles. Each role is a set of keys, and a person holds the union of their roles.
- Only while the staff profile is active. Deactivating a profile removes every role permission at once. The session stays signed in.
- Read again on every request. A change to a role or to someone’s membership applies to their very next request.
403 FORBIDDEN, and the message names the key.
Held by everyone
Every active signed-in account holds two permissions, with or without a staff role:civilians.createcivilians.manage_own
Service credentials
A service credential’s scopes are permission keys from the same catalogue. It can hold any of them exceptadmin.manage and staff.manage. Holding a scope is not always enough: endpoints that need a signed-in person refuse credentials whatever their scopes. See Authentication.
Developer Access
While temporary Developer Access is on, the session holds every permission in the catalogue. It is internal tooling, described under Authentication.The catalogue
CAD: Control
Held by dispatchers. Every Control endpoint checkscad.view first; each kind of change checks one more.
MDT: unit self-service
Held by people who crew units. These endpoints also need an active staff profile.Civilians
The first two are held by every signed-in account.PNC
Reading and each kind of official change are separate.Staff, shifts and sessions
Moderation
Oversight and administration
ER:LC
Rules that are not a single key
Some endpoints decide by ownership or membership instead of, or as well as, a permission.Endpoints with no permission key
These need a signed-in user and check no permission.
Sign-in itself is public:
GET /auth/discord and its callback need no session.
Default roles
Seeding a deployment creates these roles. Administrators can add others through the API.- Administrator is fixed. The API refuses to rename it or change its permissions, and every seed brings it up to the full catalogue.
- Other roles are created once. Seeding leaves a role that already exists exactly as it is. When a release adds a key to a default role, a deployment seeded earlier does not gain it; an administrator has to add it to that role.
- Dispatcher and Police officer are separate. A dispatcher cannot use the PNC and an officer cannot open Control unless they hold both roles.