feat(supervisor-view): define workspace access and navigation #189

New issue

Open

opened 2026-09-30 15:25:43 +00:00 by gabogg · 0 comments

gabogg commented

2026-09-30 15:25:43 +00:00

Owner

Part of #187 — milestone: Focused operator and supervisor door operations.

Intended outcome

Establish the first Supervisor workspace and its access boundary so door-management features have a coherent place to live. Current login roles are admin, operator, and viewer (app/schemas/models.py); there is no Supervisor role or dedicated view.

Agreed role boundary

Add a dedicated authenticated Supervisor role and let administrators access the Supervisor workspace. This does not change #72's door-command policy: one-shot commands remain available to authorized Operators/Admins and persistent commands remain Admin-only unless separately retriaged.

Triage questions

Who may assign the Supervisor role, and how are existing accounts migrated or granted access?
Which new management actions in the first release are Supervisor-only, admin-only, or still available to Operators?
What is the initial navigation and landing screen, and which of the child features can appear as empty states before their data workflows exist?
How are HTTP/WebSocket permissions and audit identity enforced independently of UI visibility? How does this interact with the already specified command policy in #72?

Ready-to-spec outcome

A role/capability matrix and minimal navigation contract for Operator, Supervisor, Admin, and Viewer, with server-side authorization boundaries and a staged rollout order. This issue does not create a second login-account system.

Part of #187 — milestone: Focused operator and supervisor door operations. ## Intended outcome Establish the first Supervisor workspace and its access boundary so door-management features have a coherent place to live. Current login roles are `admin`, `operator`, and `viewer` (`app/schemas/models.py`); there is no Supervisor role or dedicated view. ## Agreed role boundary Add a dedicated authenticated Supervisor role and let administrators access the Supervisor workspace. This does not change #72's door-command policy: one-shot commands remain available to authorized Operators/Admins and persistent commands remain Admin-only unless separately retriaged. ## Triage questions 1. Who may assign the Supervisor role, and how are existing accounts migrated or granted access? 2. Which new management actions in the first release are Supervisor-only, admin-only, or still available to Operators? 3. What is the initial navigation and landing screen, and which of the child features can appear as empty states before their data workflows exist? 4. How are HTTP/WebSocket permissions and audit identity enforced independently of UI visibility? How does this interact with the already specified command policy in #72? ## Ready-to-spec outcome A role/capability matrix and minimal navigation contract for Operator, Supervisor, Admin, and Viewer, with server-side authorization boundaries and a staged rollout order. This issue does not create a second login-account system.

gabogg added this to the Focused operator and supervisor door operations milestone

2026-09-30 15:25:43 +00:00

gabogg added the

needs-triage

label

2026-09-30 15:25:43 +00:00

gabogg referenced this issue

2026-09-30 15:26:53 +00:00

epic(ui): focus Operator on doors and alarms; introduce Supervisor workspace #187

gabogg referenced this issue

2026-09-30 18:45:09 +00:00

fix(auth): deny Operator statistics and enforce default authentication for every route #197