Kiosk mode
The dashboard for a wall — ?kiosk, what stops rendering, why the display signs in as a viewer, and why this is not a security boundary.
Switching it on
The same dashboard with ?kiosk on the end of the address:
https://app.runjet.dev/your-slug/?kioskIt is not a second screen but three switches over the same five bands:
- density — type, spacing and radii all grow at once, because it is one rule at the root of the page and everything is derived from it,
- overflow — on a desk you scroll; kiosk caps each band and says +12 more,
- chrome — the navigation column, the account menu and every link from a row all disappear.
The parameter applies to the dashboard only and does not travel to the other screens: it would follow an operator everywhere, and it would leave a wall one stray click away from a state nobody is there to undo.
What stops working, and what does not
Data keeps refreshing even in a tab the browser considers hidden — otherwise the display would freeze mid-countdown, which reads as data rather than as a pause. The session does not sign itself out: it lasts thirty days and is extended by use.
Sign the display in as a viewer
A wall deserves an account of its own with the viewer role (roles): it reads everything and changes nothing. Invite it like any other account (invitations), sign in on the display, and never touch it again. That the display can change nothing is a property of that role, not of kiosk mode.
It is not a security boundary
Kiosk removes controls, not rights. The session keeps everything it had: were the display signed in as an admin, a passer-by with a keyboard would delete a job — they would only have to edit the address to do it. Which is why the boundary is in the account and not in the parameter, and why the paragraph above is not a recommendation but a procedure.