Live updates
The console updates itself. When a colleague changes something, your screen follows without a reload.
What it does
Section titled “What it does”Lists refresh. A submission somebody else assigns disappears from your unassigned filter straight away.
A toast appears, saying what happened.
Dashboard numbers move as work is done.
Kiosk bookings arrive with a toast that stays until dismissed, so a repair lodged while nobody was watching the screen is still announced when somebody is.
How notifications behave
Section titled “How notifications behave”From 0.16.0, notifications are compact and sized to what they say. Most leave on their own after a few seconds; pointing at one, or moving keyboard focus into it, pauses it while you read. At most four show at once, and the oldest routine ones give way first.
Something you did that failed, such as a save that did not go through, shows in red and waits for you to close it. It does not chime: the chime and the alert styling are kept for things happening elsewhere that need attention, such as a monitor going down or a kiosk booking.
Why it matters at a desk
Section titled “Why it matters at a desk”So two technicians do not both pick up the same job.
On a busy morning that is the difference between a desk that is coordinated and two people opening the same laptop. It is the reason the queue does not need a refresh button.
What is covered
Section titled “What is covered”Submissions, tickets, loans, monitors, backups, kiosk requests, security approvals and service level breaches. The full list is in events.
What each person sees
Section titled “What each person sees”Not everybody sees the same updates, and that is on purpose.
Every update carries the permission that governs the record behind it, and the site it belongs to. Your console shows you only the updates for records you could open anyway. A casual with nothing but “view tickets” is not shown a device wipe; somebody administering one campus is not shown the other campus’s students by name.
So a colleague seeing an update you do not is normally the system working, not a fault. If somebody needs an update they are not getting, the fix is their role or their site access - see users and roles - not the stream.
Updates that belong to no single site - a backup result, a monitor alert, a fleet-wide sync - go to people who are not restricted to a site. Somebody confined to one campus will not see them.
The one thing that breaks it
Section titled “The one thing that breaks it”If you have put a reverse proxy in front of Plugboard and updates arrive in bursts every thirty seconds rather than immediately, the proxy is buffering the update stream.
It needs to pass /api/events/ straight through without buffering. The fix is a
one-line change and it is covered in HTTPS and
certificates. The bundled proxy and a tunnel do the right
thing without being asked; nginx and IIS need telling.
This looks like the application being slow, so the real cause is worth having to hand.
Other things that stop it
Section titled “Other things that stop it”| Symptom | Cause |
|---|---|
| Updates arrive in bursts | A proxy is buffering the stream |
| No updates at all | The connection is not being made. Usually a proxy or firewall closing it |
| Updates stop after a while | A proxy or load balancer is timing the connection out. Raise its idle timeout |
| Some colleagues see fewer updates than others | Usually correct - see What each person sees above. If somebody sees nothing at all rather than less, more than one copy of the application is running |
| One tab stops updating while your others carry on | You are at the per-person stream ceiling - four tabs by default. Close a tab and the one that was refused recovers on its own. SSE_MAX_STREAMS_PER_USER raises it |
One copy at a time
Section titled “One copy at a time”Plugboard runs as a single application process, and live updates are one reason why. A second copy would not know what the first one was doing, so a technician connected to one would miss changes made on the other.
If you outgrow one machine, use a bigger machine rather than a second one. For school-sized workloads this is not a limit anyone reaches: the cost is one open connection per signed-in tab, and a desk with a dozen technicians is not a load problem.
That cost is capped rather than trusted, because an open connection is not free
- each one asks the database every thirty seconds whether the person behind it is still signed in. Four streams per person, two hundred per school and two thousand in total, all of them settable: see live updates.
For developers
Section titled “For developers”The same events are available two ways: as a stream at /api/events for a
browser client inside a signed-in session, and as signed outbound
webhooks for anything server side.
Prefer webhooks for integrations. They are signed, they survive your process restarting, and they do not need a connection held open.