Staff console
/admin/ is where everything that is not a user action happens. It needs the staff flag, and the staff flag needs two-factor authentication. Every section checks DMOJ's permission codes, so a setter with judge.edit_own_problem sees the problems section and only their own problems; controls they cannot use are not rendered.
- Problems,
/admin/problems/— tabs for General, Statement, Editorial, Translations, Language limits, Clarifications, Test data, Revisions and Actions. Sets whatconfig.jsoncannot: group, types, allowed languages, per-language limits, licence, private organisations and source visibility. Actions holds rejudge, rescore, visibility and clone. - Contests,
/admin/contests/— tabs for General, Problems, People, Proctoring, Actions and Revisions. The Problems tab sets contest points, partial scoring, pretested flags, output prefix overrides, per-problem submission caps, the label scheme, and separate list release and problem publication policies; reordering changes the labels. - Submissions,
/admin/submissions/— filter by user, problem, contest, judge, status, result, language and id range, then Batch rejudge the filter as one job. One problem at a time. - Review,
/admin/review/— submissions to staff-scored problems waiting for a score, oldest first, filtered by problem or contest. Score opens the source beside a score and a note for its author; the next one opens after saving. - Scoreboards,
/admin/scoreboards/— hall scoreboard events: key, name, the contests that become divisions, theme, flag URL template, badge organisations, which means in person, freeze minutes, public or not, and organisation standings with their decay and organisations. - Jobs,
/admin/jobs/— every background job with a live progress bar, the stage it reached, who started it and any error. The first place to look when a rejudge seems stuck. - Proctoring,
/admin/proctor/— live and finished sessions. See proctoring. - Users,
/admin/users/— tabs for Profile, Permissions, Account, API keys and History. Grants permissions, resets two-factor, revokes sessions and passkeys, bans and unbans. Superusers can impersonate. - Organizations,
/admin/organizations/— name, slug, short name, description, open to join, member slots, access code, logo, administrators. Only an organisation's own administrators may review its join requests. - Classes,
/admin/classes/— subdivisions of an organisation, so a contest can be restricted to one tutorial group. - Tickets,
/admin/tickets/— user reports about problems. Reassign, close or delete. - Judges,
/admin/judges/— status, tier, ping, load, problem count, runtimes, last seen, address. Creating one shows its key once. Disable stops work reaching it, Block rejects its calls, and Disconnect is picked up at its next heartbeat. - Languages,
/admin/languages/— key, name, short name, common name, extension, editor mode and highlighting. Copying one language's problem set onto another replaces the target's set. - API keys,
/admin/api-keys/— mints and revokes your own keys, and prints the base URL and a workflow snippet for a problem repository. - Navigation,
/admin/navigation/— the navigation bar as an ordered tree: label, path, highlight regex and parent. - Config,
/admin/config/— Site settings for identity, account rules, submission limits, points, ratings and page sizes; Misc config for DMOJ's key and value store. - Branding,
/admin/config/branding/— site name, wordmark, favicon, accent and nav colours, default theme and custom CSS, with a contrast-checked preview. Superusers only; an empty field restores the default. Logo uploads save their dimensions so the header reserves the correct width before the image loads. After upgrading an existing deployment, re-upload its custom logo and save once to capture these dimensions. Until then, the logo fits the default wordmark's proportions. The bundled logo needs no migration. - Flat pages,
/admin/flatpages/— static pages such as/about/. - Blog,
/admin/blog/— posts with authors, publish time, visibility, sticky flag, summary and body. A future publish time schedules the post. - Licenses,
/admin/licenses/— the licences a problem can carry, shown at/license/<key>. - Tags,
/admin/tags/— contest tags with a name, colour and description.
A language existing here does not make it submittable: the submit page offers a language only when an online judge reports a runtime for it.
Contest release settings
The contest's Problems tab has two independent controls:
| Control | Choices | Effect |
|---|---|---|
Show contest problem list (problemListReleaseAt) | Start, end, never | Releases the list to viewers who can view the contest. Does not change problem visibility. |
Publish problems to the general problem set (publishProblemsAt) | Start, end, never | Makes eligible private problems public. Does not release the contest list. |
The new-contest wizard combines these under Release contest problems, defaulting both to the start. Its start, end or never choice sets both policies; after creation, use the Problems tab to change them independently. Existing rows without problemListReleaseAt and imported DMOJ contests use the start policy for the list; an explicit null means Never. Participant and privileged access are described in problem list release.
List release is evaluated against the current policy and contest times. Choosing Never or moving the selected boundary into the future hides it again from general viewers. In contrast, changing publication settings never makes public problems private again. If the two controls have different timings, the console warns that viewers may see restricted entries, or public problems before the contest list is shown.
Publication runs on a five-minute sweep, or when a contest is saved after its selected boundary. A private problem is held back if another future or running contest uses it, unless that contest has already started and also publishes problems at its start. Showing another contest's list does not permit publication.
Publication records revisions and queues rescoring for newly public problems. It is a one-time attempt, recorded in problemsPublishedAt, even if some problems were held back. Later saves and sweeps do not retry those problems or override staff visibility changes. Review the contest revision for held problems and publish them separately when appropriate.
Revisions
Every edit writes a revision: a whole snapshot of the entity, who made it, when, and the reason typed into the reason field, which is not optional. Problems, contests, users and organisations show their history in the console, and on a problem or a contest the panel compares any two revisions field by field.
Revisions record staff edits, not user actions. A problem published through the API records the upload, not the statement's history; that is what the repository's git log is for.