Make service accounts assignable to incidents (assigned_to_service_account_id) #36

New Issue

2026-10-08T07:32:20Z

niklas commented

2026-10-08 07:32:20 +00:00

Follow-up to #35 (shipped in v0.39.0), which records who performed an assignment but left service accounts unassignable.

Today incidents.assigned_to is a users(id) FK, so only a human can be the assignee. Migration 015 (#25) deliberately did not add assigned_to_service_account_id, and 018 (#35) did not either.

What it touches

Migration: incidents.assigned_to_service_account_id (nullable FK to service_accounts, ON DELETE SET NULL, exclusive with assigned_to via a CHECK, same shape as acknowledged_by_service_account_id in 015).
handleIncidentAssign (internal/api/incidents.go): request body currently {"user_id": N}; needs a way to name a service account (e.g. service_account_id, exactly one of the two). assigned events need an assignee column for a service account too (incident_events.user_id cannot hold it).
incidentSelectFrom / scanIncident and models.Incident: add the service-account assignee id/name (omitempty, additive JSON).
GET /api/incidents?assigned_to= filter: decide whether it also accepts service accounts.
Notifier (internal/api/notifier.go, the AssignedToUser use): a service account has no ntfy topic, so decide what a page for such an incident does.
Web UI: the assignee picker in incident.js and the queue's → name label.
terdut-tui: mirror the new JSON in internal/api/client.go and types.go.

Open question

Whether this is wanted at all: a service account can act on incidents, but nobody gets paged for one it owns. If the use case is only "operator marks an incident as taken by automation", an assignee-less marker may fit better than a full assignee.

Follow-up to #35 (shipped in v0.39.0), which records who *performed* an assignment but left service accounts unassignable. Today `incidents.assigned_to` is a `users(id)` FK, so only a human can be the assignee. Migration 015 (#25) deliberately did not add `assigned_to_service_account_id`, and 018 (#35) did not either. ## What it touches - Migration: `incidents.assigned_to_service_account_id` (nullable FK to `service_accounts`, `ON DELETE SET NULL`, exclusive with `assigned_to` via a CHECK, same shape as `acknowledged_by_service_account_id` in 015). - `handleIncidentAssign` (`internal/api/incidents.go`): request body currently `{"user_id": N}`; needs a way to name a service account (e.g. `service_account_id`, exactly one of the two). `assigned` events need an assignee column for a service account too (`incident_events.user_id` cannot hold it). - `incidentSelectFrom` / `scanIncident` and `models.Incident`: add the service-account assignee id/name (omitempty, additive JSON). - `GET /api/incidents?assigned_to=` filter: decide whether it also accepts service accounts. - Notifier (`internal/api/notifier.go`, the `AssignedToUser` use): a service account has no ntfy topic, so decide what a page for such an incident does. - Web UI: the assignee picker in `incident.js` and the queue's `→ name` label. - `terdut-tui`: mirror the new JSON in `internal/api/client.go` and `types.go`. ## Open question Whether this is wanted at all: a service account can act on incidents, but nobody gets paged for one it owns. If the use case is only "operator marks an incident as taken by automation", an assignee-less marker may fit better than a full assignee.

niklas referenced this issue from a commit

2026-10-08 12:19:15 +00:00

Draw the rota as shift bars, and the escalation chain as a ladder

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: niklas/terdut-server#36