2 Commits

Author	SHA1	Message	Date
Niklas Ye	9da913080f	Stop 500ing when a service account acts on an incident ... Every incident-mutation handler read userFromContext(ctx) and wrote the result's .ID into acknowledged_by/incident_events.user_id without checking the ok bool. For a team-scoped service-account caller this returned a zero-value user id, which violated the users(id) FK and 500'd on acknowledge, unacknowledge, resolve, snooze, unsnooze and create-note. handleDeleteNote didn't crash but silently matched zero rows instead (WHERE user_id = 0), so a service account could never delete its own note. Add acknowledged_by_service_account_id (incidents) and service_account_id (incident_events) as nullable FKs to service_accounts(id), parallel to and mutually exclusive with the existing human columns (migration 015, with a CHECK enforcing the exclusion). Route every one of the six handlers plus delete-note through a new callerActorIDs() helper that branches on Caller.AsHuman()/ServiceAccountID() instead of assuming a human, and thread a serviceAccountID parameter through logEvent and the new acknowledgeIncidentAs (acknowledgeIncident itself is untouched: its only other caller, the push-notification Acknowledge button, is always human). Render the new actor distinctly from both a human and "the server acted" in the web UI's incident timeline and facts card. handleIncidentAssign, handleIncidentArchive and handleIncidentUnarchive are deliberately not touched here — they track no actor at all today, for anyone, which is a separate pre-existing gap (follow-up issue to come). Fixes #25	2026-10-07 21:09:31 +02:00
Niklas Ye	774fdfcaa8	internal/api: unify human/service-account authz into one Caller type ... ctxUser/ctxTeams (human) and ctxServiceAccount (+ a synthetic ctxTeams entry, service account) used to be two parallel, un-unified context representations -- every authz predicate had to remember which one(s) it needed, and every place that forgot either wrongly 403'd a service account (terdut-server#23, terdut-operator#3), crashed on an unchecked zero-value user id, or silently no-op'd. New internal/api/caller.go collapses both into one Caller, stored under one ctxCaller key by serveAs/serveAsServiceAccount; every existing predicate (userFromContext, callerTeamIDs, callerRole, callerIsAdmin, isInstanceServiceAccount, AdminOnly, requireSelfOrAdmin, requireTeamOwner, OperatorModeBlock) now reads through it, with identical behavior for every untouched call site (alerts.go, incidents.go, schedule.go, stats.go, etc.) -- confirmed by the full existing suite passing unchanged. Four real fixes land alongside the refactor, not just the restructuring: 1. callerMayManageServiceAccount gains the one load-bearing branch this exists for: an instance-scoped service account may now manage (mint or revoke a key on) any team-scoped account, not only a human admin, that team's human owner, or the account itself. handleCreateServiceAccount already let an instance-scoped caller *create* a team-scoped account for any team; adopting or rotating one it didn't just create in the same call -- terdut-operator's own documented crash-window recovery -- had no equivalent permission and 403'd forever. Closes terdut-operator#3. 2. handleCreateInvite wrote a service-account caller's zero-value user id straight into invites.created_by (nullable, but never passed as nil), which foreign-key-violates against users(id) -- a 500, not success, for any team-scoped service account minting an invite. Fixed the same way handleCreateServiceAccount already handles the analogous case. Found live while verifying this change, not filed separately since it's fixed in the same place it was found. 3. handleMe and handleTestNotification 500'd for a service-account caller (fetchUser/the ntfy_topic lookup against a zero-value user id that matches no row); handleDismissOnboarding silently no-op'd (UPDATE ... WHERE id = 0). All three now call Caller.AsHuman() and return an explicit 403 ("this endpoint is for human accounts only"). 4. Ratifies, rather than further narrows, two capabilities a team-scoped service account already had by construction and this document's own text once called "a gap acknowledged rather than closed": owner-equivalent reach over membership/invites, and minting another service account for its own team. terdut-operator's new TerdutTeam invite-minting feature is about to depend on the first one, so this makes it documented, tested, intentional behavior instead of an accident nobody was supposed to rely on. AdminOnly/requireSelfOrAdmin are unchanged in effect: still human-only, forever, for every scope of service account -- confirmed by TestAdminOnly_RefusesEveryServiceAccountScope. terdut-server#23's named routes (POST /api/users, PUT /api/admin/settings) were never the right thing to widen; its real fix is the terdut-operator invite feature, recorded in SERVICE-ACCOUNTS.md's "What this unblocks" and closing that issue once it ships. SERVICE-ACCOUNTS.md amended in place (not a new file, its own established convention) to describe the as-built Caller model, correct its own aspirational claim about AdminOnly that TEAM-LOOKUP.md had already flagged as not matching shipped code, and record all of the above.	2026-10-02 21:52:43 +02:00