ROKRescue Operator Knowledge

How it works

How access works

Why ROK grants access through groups rather than job titles, what the role field actually does, and where the real boundary sits.

Most systems ask "what is this person?" and hand out access by title. ROK asks "what should this person be able to do?" and hands out permissions, bundled into groups.

How a permission is resolvedPersonone profileGroupReviewersGroupAuthorsPermission keyscontent.publish, …Alloweduser_roledisplay hint onlyNothing consults this. Changing it grants nothing.Permissions are the union of every group the person belongs to — in the active tenant only.Group membership is per tenant, so the same person can be an author here and an operator elsewhere.Checked in Postgres by has_permission()
A person reaches a permission only through the groups they belong to.

Groups, not titles

A permission is a single capability — Publish, Manage groups, Award badges. A group is a named bundle of them. A person belongs to any number of groups, and what they can do is the union of every group they're in.

That means:

  • Giving someone one extra capability doesn't require inventing a new job title.
  • Removing someone from a group removes exactly what that group granted, and nothing else.
  • Two people with the same title can legitimately differ, which is how real agencies work.

Your groups are listed under People & access → Groups (opens the admin console), and the full catalog of permissions — in plain language — is at Permissions (opens the admin console).

The role field grants nothing

Each person also has a role value that reads operator, author or similar. Nothing consults it. It is a display hint so lists have something human to show.

If you want to know what someone can actually do right now, open their profile from Users (opens the admin console). The effective permissions panel lists the resolved union, and names which group granted each one.

It is per tenant

Group membership belongs to a tenant, not to a person globally. Someone who works with two agencies has one login and one profile, but separate memberships — an author in one, an operator in the other. Switching the active agency switches which set applies.

Hiding a button is not security

The console hides controls you can't use, so the screen stays honest. That is presentation.

The actual check runs in the database on every read and write. If someone reached a hidden control — by URL, by an old bookmark, by anything — the database still refuses. This is worth knowing for a practical reason as well as a reassuring one: when an action is refused despite the button being visible, the answer is a missing permission or an unmet condition, not a broken screen.

Two things groups don't govern

  • Getting into the agency at all. Operators join by redeeming an access code; staff are invited by someone with Manage users. See Access codes (opens the admin console).
  • Being suspended. Suspension is separate from group membership. A suspended person keeps their groups and still can't get in — which is what you want when the situation is temporary.

See also

Last reviewed