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.
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.
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. Caddy and Cloudflare 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 updates, others do not | More than one copy of the application is running. See below |
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, the answer is 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.
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.