Who may do what

One pair of hands, two halves

Neither role is dangerous. Together they are, and no constraint on a role can see it — a role holding both grants is refused by a test, but a person holding two safe roles is not something the database can notice. That is what this table is for.

This is not automatically an error. On day one it is the owner, which is correct: there is one, and they are the business. It is here so that the day a second name appears, somebody sees it.

A second thing as well as a password

A password is one thing, and it is the thing that gets read off a note, reused from a shopping site, or typed into a page that only looked like this one. A six-digit code from an app on a phone is a second thing, and somebody who has the password without the phone gets nowhere.

Turning this on asks for one only from the accounts that can write money, identity documents, a rider's payee details, other people's accounts, privacy erasures or the platform. A picker at a bench gets no new step. Anybody may set one up whether or not it is on, on their own sign-in page.

Ask for a second factor

Give somebody a login

The account is created straight away and cannot sign in until they set their own password through a single-use link. You never see it, and neither does anybody else — which is why this exists rather than a box where you type a starting password for them.

Links that have not been used

Given an account, never got in

Their link expired before they used it. Nothing else here mentions them — they are not disabled and not locked out, so they would simply stay invisible until somebody asked why they had never signed in.

Not used for a month

A live login nobody has used in thirty days — or ever, given long enough ago that "never" means something. Two different people are on this list: somebody who has left, whose account should be disabled, and somebody who never took the system up, who should be asked what stopped them. Riders are on Riders and merchants on Partners; dispatchers can be disabled below.

Everybody with an account

A role is a bundle of grants and the grants are what matter. "Give Ama pricing" is not a sentence anybody can evaluate; the areas column is the same fact in a form you can decide about. Grants are read from the database on every request — never carried in a cookie — so a change here is in force on somebody's very next click, with no sign-out.

What each role can do

Read from role_grant, not written into this page — a role is a row, so one added by a migration explains itself here without anybody editing this screen. owner holds every area and is not grantable: there is one per business, enforced by a unique index, and it is set with admin.ts role:owner on the box. Roles marked yours were written here and can be changed; the rest come with the system and are the same in every business using it.

Write a role

A role is a name for a set of grants; nothing in the system ever compares against the name itself. Start from one that is close, change what it reaches, and save it under a new name. Write includes read on the same area, so ticking write is the whole grant.

What the areas mean