Live Monitoring
The monitoring board shows an exam while it is still happening: who is in the room, how far through they are, how long they have left, and who has gone quiet. From the same screen you can intervene on a single attempt — extend time, allow a resume, pause, force a submit, or leave a note.
The board runs in two places from one implementation: as a route in the management application, and as a standalone page on the site that can be given to an invigilator who has no Joomla account at all.
What the board shows
| Column | Meaning |
|---|---|
| Examinee | The person sitting the exam, or the guest identity they supplied |
| Progress | Answered questions out of the total in their frozen paper |
| Time remaining | Computed from the server clock, accounting for any paused time |
| Last seen | When their browser last checked in |
| Status | In progress, paused, or held |
| Integrity | Captured signal counts, where the exam records them |
Progress counts are real. They are computed with the same rule the grader uses to decide whether a response is unanswered, rather than a naive "is there a row" test. That distinction matters: an emptied answer is stored as an empty structure, not as nothing, so a naive count over-reports — and over-reporting tells an invigilator that a stuck candidate is fine.
How it stays current
The board polls. Each examinee's browser also sends a lightweight heartbeat so last seen is meaningful even when they are reading rather than typing.
Three intervals are configurable, each with a non-zero floor so the board cannot be turned into a self-inflicted denial of service:
| Setting | Range | What it controls |
|---|---|---|
| Poll interval | 3–300 seconds | How often the board asks for an update |
| Stale threshold | 15–3600 seconds | How long without a heartbeat before someone is flagged as quiet |
| Ping interval | 10–600 seconds | How often the examinee's browser checks in |
A quiet room is nearly free. Before building the board, the server computes a cheap fingerprint of the room; if nothing has changed since the last poll, it returns a tiny unchanged response instead of rebuilding and re-sending the whole board. A busy room rebuilds every time — correctly, because it genuinely changed.
The fingerprint deliberately refuses to answer while there is activity newer than one poll interval. Last-seen times have one-second resolution, so two saves either side of a board build within the same second could otherwise stay invisible; when in doubt, the board rebuilds.
A server-sent-events transport is also implemented and can be enabled. It removes HTTP round trips but does not reduce latency — the server still re-checks at the same interval either way.
Interventions
Actions apply to one attempt.
| Action | Effect |
|---|---|
| Extend time | Adds time to that attempt's remaining clock |
| Allow resume | Lets an attempt that would otherwise be closed be resumed |
| Pause exam | Freezes the attempt |
| Release | Un-pauses it |
| Force submit | Ends the attempt and submits what is there |
| Set note | Attaches an invigilator note to the attempt |
Every action is written to an audit log against the attempt it touched, recording who did what and when. Automatic closures appear there too, attributed to Automatic — so an attempt that ended without anyone touching it still says why. Those entries are records only; nobody can invoke an automatic closure as an action, whatever their permissions.
You do not have to force-submit everyone who goes quiet. An attempt whose examinee has closed their browser is closed on its own, following the exam's auto-close policy. Force submit is for the case you want ended now rather than at its deadline. Opening this board is itself one of the things that triggers the sweep, so a room you are watching keeps itself tidy.
Actions are applied as narrow, targeted updates to the specific attempt and only while it is still in progress. They never rewrite the attempt wholesale, because the examinee's own browser is still saving to the same record — a broad write would simply be overwritten by their next autosave.
Accountless invigilators
You can hand invigilation to someone without creating a Joomla account for them. Two kinds of grant:
| Type | How it works |
|---|---|
| Link | A long random token in a URL. Only a hash is stored; the full link is shown once, when you create it. |
| PIN | A six-digit code entered on the monitor page. |
A grant is always scoped to exactly one exam. There is no all-exams grant, and this is a deliberate refusal rather than a missing feature: an unscoped link would expose every examinee in the system to whoever the link reached.
A grant can never end anyone's exam. Grants may view, extend time, allow a resume and set notes. Force-submit and pause are structurally excluded — the capability set carried by any grant is intersected against the permitted list, so a leaked link cannot end an exam however the grant was configured.
PINs are protected differently from links, because six digits is only a million possibilities. They are stored with a slow password hash rather than a fast digest, and — more importantly — PIN entry is rate-limited per IP address, five attempts before a lockout. The rate limit is what actually stops guessing.
Access control
| Action | Required capability |
|---|---|
| View the board | monitoring — view |
| Extend time | monitoring — extend_time |
| Force submit | monitoring — force_submit |
| Allow resume | monitoring — allow_resume |
| Pause and release | monitoring — pause_exam |
| Set a note | monitoring — set_note |
| Issue or revoke grants | monitoring — manage_grants |
Releasing a paused room maps to the same authority as pausing it — un-pausing is not a lesser act than pausing.
The monitoring endpoints are reachable without a Joomla login, because an invited invigilator is a guest as far as Joomla is concerned. Every one of them therefore authorises itself, against either a monitoring role permission or a redeemed grant. For an action on a specific attempt, the exam it belongs to is re-read from the attempt itself rather than taken from the request, so a grant for one exam cannot be used to act on an attempt in another.
Roles seeded at installation reflect this split: an exam administrator gets everything, a proctor gets a working subset, and author, grader and viewer roles get view-only access.