Giving somebody access¶
/access, moderator-only. One person at a time, and everything they hold on
one screen.
Access used to live in three screens over two tables — category grants in the question manager, library grants in the image bank, nothing at all for articles — so nobody could see what one person actually had.
The page¶
Pick somebody from the list on the left; their name carries a summary — No access, Everything, or "3 branches, 1 library".
| Section | Grants |
|---|---|
| Everything | The moderator role, not a grant. Every question, article and image library, including anything added later. |
| Question and article branches | A category and everything beneath it |
| Question folders | Exactly the questions somebody put in the folder |
| Image libraries | One library |
A granted branch shows its children as covered by a parent rather than as separately grantable, with the checkbox disabled: the grant already reaches them, and offering a checkbox that changes nothing is how a permissions screen starts lying.
Each row carries its reach — N q, N articles — so you can see what you are handing over before you hand it over.
Deciding what to give¶
Start from the work, not from the tree:
| They will be | Give |
|---|---|
| Writing and fixing questions and articles on a subject | The branch for that subject |
| Looking after these forty specific questions | A folder |
| Uploading and describing images | The library |
| Writing an article that uses pictures | Both — the branch says what they may write about, the library says which pictures they may use. Neither is a way into the other. |
| Looking after a set of decks | A deck grant, which is written at /flashcards/grants, not here |
A branch is a description, and it keeps covering things filed there later. A folder is a list, and it covers exactly what is in it.
What the page deliberately does not offer¶
- Exam-scoped and tag-scoped grants exist in the schema and in the
permission predicate —
category_grantshas four nullable target columns and they combine with AND — but nothing in the interface writes them. - Deck grants are elsewhere.
- Roles, when the identity provider decides them. The page then says so and names the provider, instead of drawing a control that can only fail.
Refusals you will meet¶
| Message | Means |
|---|---|
| This person already has everything; a grant would add nothing | They are a moderator or an admin. Take that away first, or do nothing. |
| An administrator's role is not changed here | Use Settings → People, which is admin-gated. |
| Change someone else's access, not your own | You cannot demote yourself here. |
| Already granted | The exact grant exists. A covered child is not granted again. |
A 409 on the role switch |
Roles come from the provider. Change their group there. |
Clear all access¶
One button on the person, and it does exactly what it says: every category,
library and folder grant goes, including the branches reached through a
parent, because removing the parent removes them. If they held "everything",
the role goes back to user as well.
It is not offered for an administrator, and not for yourself.
After you have granted something¶
Send them to Editorial (/editorial) and
Questions (/questions/manage). Both are
open to any grant holder and both scope themselves to what the person holds.
The bin, the taxonomy, the uploader, the job list and the change log stay moderator-only: those are decisions about the whole bank rather than about one branch of it. What a grant does not carry is listed in Grants, and the rule every grant relies on is in What can be undone.
Checking what somebody did¶
/changes (moderator-only) merges question_versions and
article_revisions into one newest-first list: kind, id, title, who, when, and
the note. Filterable by person, capped at 500. It records nothing of its own.
It is moderator-only rather than open to grant holders because it names people and what they did — that is oversight, not editorial work.