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

New issue

Open

opened 2026-09-30 15:22:08 +00:00 by gabogg · 0 comments

gabogg commented

2026-09-30 15:22:08 +00:00

Owner

Outcome

Make the Operator workspace focused on live doors and alarms, then introduce a Supervisor workspace for managing doors and their operational context. This milestone includes manual status records for existing doors where HikCentral telemetry is unreliable, a separate operator directory (not login-account management), selected-door open-time reporting, better exclusion management, and persistent labels. The child issues remain needs-triage: they capture the intended direction and decisions still required before implementation.

Current seams

The shared content-doors deck currently combines the door portal matrix with occupancy telemetry. Authentication roles are admin, operator, and viewer; there is no Supervisor role yet.
Door exclusions already have AUTO and MANUAL provenance, and /api/doors/override is admin-only. Current rankings measure doors open now, while door_access_cycles and hardware transitions hold historical data.
#72 already specifies door-command role policy and audit. Triage how that work relates to Supervisor access; do not duplicate or silently change its settled policy.

Design tree to settle during triage

Workspace boundary: which remaining door and alarm details and actions belong to Operators versus Supervisors and administrators?
Door records: which metadata survives synchronization, and how do human status assertions for existing doors coexist with unreliable HikCentral telemetry (precedence, provenance, expiration)?
People records: which fields belong in the separate staff directory, and how are they linked to actions without becoming another login system?
Historical questions: how is open time measured over a chosen interval, including incomplete cycles and sensorless doors?
Policy and vocabulary: which exclusions affect rankings, alerts, reports, and counts; what are labels and who may edit them?

Scope guard

This declaration starts the product/design triage. It does not authorize a new login-account management UI, a change to #72's settled command permissions, or an alarm acknowledgement workflow before those decisions are made explicitly.

Decisions already made

Supervisor is a dedicated authenticated role; administrators can enter its workspace. #72's one-shot and persistent door-command permissions remain as specified until separately changed.
Operator focuses on live door states, open-longest ranking, door activity, alarms, and permitted one-shot controls. Occupancy, configuration, and diagnostics move out of that view.
The first operator-registry stage is a staff directory separate from login accounts; shift management is not part of this initial decision.
Manual status means human-entered status for an existing door when HikCentral reporting cannot be trusted. It does not mean manually creating door identities or a generic incident log. Show raw and manual status together, with the valid manual status identified as the operational assessment. Supervisor/Admin entry requires a reason and audit trail. Every entry needs a one-day, one-week, or one-month reconfirmation deadline; no indefinite option. Keep hardware alarms visible and show manual records separately from hardware-derived open-time calculations while calculation rules are unsettled.

Child issues

#188 — Operator doors-and-alarms scope.
#189 — Supervisor access boundary and workspace navigation.
#190 — Existing door inventory and locally maintained metadata.
#191 — Manual status records for existing doors with unreliable telemetry.
#192 — Separate operator/person records, not login accounts.
#193 — Selected-door open-time reporting over a range.
#194 — Exclusion scope, provenance, and review.
#195 — Persistent door labels and grouping.

Triage #188 and #189 first because their role/workspace details affect every other child. Triage #190 and #191 together to settle field ownership and status presentation; #193 and #194 need a shared policy for manual status, exclusions, and incomplete door history. Link #72 as a prerequisite only if the chosen Supervisor permissions require it. Close this umbrella when the agreed milestone scope is delivered; keep every implementing PR and prerequisite selected for this feature in the milestone.

## Outcome Make the Operator workspace focused on live doors and alarms, then introduce a Supervisor workspace for managing doors and their operational context. This milestone includes manual status records for existing doors where HikCentral telemetry is unreliable, a separate operator directory (not login-account management), selected-door open-time reporting, better exclusion management, and persistent labels. The child issues remain `needs-triage`: they capture the intended direction and decisions still required before implementation. ## Current seams - The shared `content-doors` deck currently combines the door portal matrix with occupancy telemetry. Authentication roles are `admin`, `operator`, and `viewer`; there is no Supervisor role yet. - Door exclusions already have `AUTO` and `MANUAL` provenance, and `/api/doors/override` is admin-only. Current rankings measure doors open now, while `door_access_cycles` and hardware transitions hold historical data. - #72 already specifies door-command role policy and audit. Triage how that work relates to Supervisor access; do not duplicate or silently change its settled policy. ## Design tree to settle during triage 1. **Workspace boundary:** which remaining door and alarm details and actions belong to Operators versus Supervisors and administrators? 2. **Door records:** which metadata survives synchronization, and how do human status assertions for existing doors coexist with unreliable HikCentral telemetry (precedence, provenance, expiration)? 3. **People records:** which fields belong in the separate staff directory, and how are they linked to actions without becoming another login system? 4. **Historical questions:** how is open time measured over a chosen interval, including incomplete cycles and sensorless doors? 5. **Policy and vocabulary:** which exclusions affect rankings, alerts, reports, and counts; what are labels and who may edit them? ## Scope guard This declaration starts the product/design triage. It does not authorize a new login-account management UI, a change to #72's settled command permissions, or an alarm acknowledgement workflow before those decisions are made explicitly. ## Decisions already made - Supervisor is a dedicated authenticated role; administrators can enter its workspace. #72's one-shot and persistent door-command permissions remain as specified until separately changed. - Operator focuses on live door states, open-longest ranking, door activity, alarms, and permitted one-shot controls. Occupancy, configuration, and diagnostics move out of that view. - The first operator-registry stage is a staff directory separate from login accounts; shift management is not part of this initial decision. - Manual status means human-entered status for an existing door when HikCentral reporting cannot be trusted. It does not mean manually creating door identities or a generic incident log. Show raw and manual status together, with the valid manual status identified as the operational assessment. Supervisor/Admin entry requires a reason and audit trail. Every entry needs a one-day, one-week, or one-month reconfirmation deadline; no indefinite option. Keep hardware alarms visible and show manual records separately from hardware-derived open-time calculations while calculation rules are unsettled. ## Child issues - #188 — Operator doors-and-alarms scope. - #189 — Supervisor access boundary and workspace navigation. - #190 — Existing door inventory and locally maintained metadata. - #191 — Manual status records for existing doors with unreliable telemetry. - #192 — Separate operator/person records, not login accounts. - #193 — Selected-door open-time reporting over a range. - #194 — Exclusion scope, provenance, and review. - #195 — Persistent door labels and grouping. Triage #188 and #189 first because their role/workspace details affect every other child. Triage #190 and #191 together to settle field ownership and status presentation; #193 and #194 need a shared policy for manual status, exclusions, and incomplete door history. Link #72 as a prerequisite only if the chosen Supervisor permissions require it. Close this umbrella when the agreed milestone scope is delivered; keep every implementing PR and prerequisite selected for this feature in the milestone.

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

2026-09-30 15:22:08 +00:00

gabogg added the

needs-triage

label

2026-09-30 15:22:08 +00:00

gabogg referenced this issue

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

feat(operator-view): focus on doors and alarms #188

gabogg referenced this issue

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

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