The manager panel
Thirteen areas, and why you see only some of them.
The panel lives at /manager. Its landing screen lists what you may open and
nothing else: everything you may administer here — what you may not is not
listed.
That is not decoration. The sidebar, the landing screen and the guard on every route all read one table, so a card cannot offer you a screen that then answers 403, and a screen you can reach cannot be missing from the menu.
The thirteen areas
Holding any one of the permissions in the last column opens the area.
| Area | What it is for | Any one of these admits |
|---|---|---|
| Users | Accounts, temporary logins in bulk, blocking and notes. | user:read:all |
| Grants | Who may do what, in the system and in each activity. | grant:read:all |
| Roles | The sets a grant links. Editing one reaches everybody holding it. | role:read, role:manage:activity, grant:update |
| Problems | The library: statements, attachments, packages and versions. | problem:read:own, problem:read:all |
| Activities | Contests and courses: series, assignments, times and enrollment. | activity:create, activity:update, activity:archive |
| Submissions | Every submission, its source, its attempts and a rejudge. | submission:read:all |
| Questions and announcements | Answering, publishing an answer to everyone, announcing. | question:read:all, question:answer |
| Printouts | The queue of source somebody asked to have on paper. | printout:manage |
| Runners | The machines that evaluate: approval, tags and their reports. | runner:read |
| Instance | What this installation is called, the mark it shows, and the documents it publishes. | instance:update |
| External logins | Identity providers, what a claim from one grants, and the accounts asked to go. | provider:manage |
| LTI platforms | Course platforms that may open activities for their students. | provider:manage |
| External content | Where this installation may fetch documents from, and whether it may at all. | instance:update |
Hold none of them and the panel has nothing in it for you: neither the entry in the navigation nor the landing screen appears.
What "you hold it" means here
An area is offered when you hold its permission anywhere — in one activity is enough. Somebody who runs a single course still needs the panel that course lives in.
Users is the one exception, and it asks for its key at system scope. Its
key, user:read:all, is in the shipped manager role so that the enrollment and
grant pickers have somebody to choose from; read the usual way, the card would
appear for every activity manager and the list behind it would refuse.
The screens themselves are stricter. Inside an activity, what you may hand out is what you hold in that activity, which is not the same set as your rights across the installation. See Permissions and grants.
Where the manager's job stops
Six of the thirteen areas are about the installation rather than about any one
activity: Users, Runners, Instance, External logins, LTI platforms and External
content. Between them they need four permissions — user:read:all,
runner:read, instance:update and provider:manage. Three of the four are
not in the shipped manager role, and user:read:all is there only so that a
manager can name a person — the Users area itself asks for it at system scope.
Running an activity is not running the installation it lives in.
Roles is on both sides of that line. Writing an activity's own roles is
role:manage:activity, held in the grant on that activity and carried by the
shipped manager role — so a manager corrects what their own participants hold.
Writing the installation's roles is role:manage, which is global and an
administrator's: a role the installation shares is reachable from every
activity, so writing one is an installation-wide act.
Printouts is the one written to be handed out on its own. A grant carrying
printout:manage and nothing else opens that area and refuses every other one,
which is how somebody standing at a printer is given that job and no other. The
cost is stated on its page: the key makes them staff in that activity, and staff
are not in its ranking.
Updates, and turning them off
Every screen in the panel carries the same two controls at the top: a button reading Updates on or Updates off, and Refresh.
Left alone, the panel keeps itself current: a question arriving, a submission finishing, somebody joining, a Runner appearing all reach the list you are looking at without you doing anything. Switching updates off stops that for the whole panel — every screen, until you switch it back on — so a list you are reading through holds still. An orange Changes waiting appears when something has moved meanwhile; it says what kind of thing, and deliberately not how many, because one rejudge is several messages about one submission.
Turning updates back on reads everything again. So does Refresh, without turning them back on. And while a dialog is open the panel holds still by itself, whatever the switch says.
These are not the round's Pause and Resume
Pausing a round is a different control, on the activity's own screen, and it stops the contest: it accepts no submissions and its clock stands still. This switch changes nothing anybody else can see — it is about your screen, not about the competition.
Beyond even those is a third reader. Installing AlgoJudge, backing it up, updating it and getting it back after a failure is not done from this panel at all; it is Install and operate.