7 Commits

Author	SHA1	Message	Date
Niklas Ye	ac9af8e4f5	Manage a person's account and teams from one page ... The Admin tab could make somebody an administrator and disable them, and nothing else. Setting a first password, deleting an account and seeing which teams a person is in all meant curl, and the last one meant opening each team in turn — the Team tab answers "who is in this team", which is the wrong way round when the question is about a person. A name in the user list now opens /admin/users/{id}: their email and when they joined, where their notifications go, the administrator and disabled flags, the teams they are in with their role in each, a password field for a first or forgotten one, and deletion. A section of its own rather than an expanding row, because memberships and the account actions together are more than a table row can hold and still be read on a phone. Adding somebody mints an invite link into a chosen team rather than creating a bare account. POST /api/users makes a user with no password and no team, who can sign in nowhere and would see nothing if they did; the invite machinery from #7 already solves both, and the password is chosen by the person it belongs to instead of passing through an administrator. One new endpoint, GET /api/users/{id}/teams, self or admin. /api/teams is always about the caller and cannot be asked about anybody else. It 404s for a user who does not exist, so the page can tell "in no teams" from "no such person" — an empty list is a real answer and needed to stay one. No authorisation changed, and the interesting part is why it did not. requireTeamOwner has accepted the administrator flag since a4fbd60, with the reason in its own comment: somebody has to be able to repair a team whose owner has left. It guards nine call sites, so an administrator has always been able to configure any team on this server — while #1's decision table and this README both said an admin "is not implicitly in every team", full stop. The code was right and the prose was wrong in the safe-sounding direction, which is the worse way round to have it. So the documentation moved to meet the code. The Teams table marks owner as owner-or-admin, and the Authentication section states the two directions separately: an administrator configures any team, and reads none, because callerTeamIDs is built from real memberships only. Joining a team to see its queue is a membership change and shows as one. TestAdmin_ConfiguresATeamTheyAreNotIn pins both halves — the admin renames, invites, adds and removes on a team they are not in, then sees zero of its incidents. Nothing tested this from v0.12.0 to here, which is why four releases of prose could contradict it quietly. The UI has not been opened in a browser. Its wiring is checked — every cross-module import resolves, every api.* call exists, every CSS class has a rule, and the deep link serves index.html — but nobody has clicked through it, least of all at phone width. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-21 12:55:42 +02:00
Niklas Ye	b39aac36b7	Add the sign-up page and the first-run checklist ... Second half of #7. The API could create accounts from invite links since the last change; this is the part somebody can actually use. /signup is the one route that works without a session. It asks the server what it may offer before showing anything: an invite link that is good names the team it leads to, a link that is not says so before somebody picks a password rather than after, and an invite-only server with no link says that instead of presenting a form it will refuse. The login card only offers "create one" when sign-up is open, so the door nobody can walk through is not advertised. Signing up signs you in and lands on the queue, because the alternative is a form saying "now go and log in" about the credential just chosen. The checklist is the other half. Four things have to be true before an alert reaches a phone -- a notification topic, somebody on the rota, an alert source, and an alert that has actually arrived -- and on a fresh install none of them are. It sits above the queue until they are. It is computed from the data rather than from stored progress: a topic is set or it is not, an integration exists or it does not. That means it cannot claim a step is done when it is not, and it comes back by itself if somebody deletes their integration a month later. The only stored state is the dismissal, which is per user and not per browser -- finishing on a laptop should not leave the phone nagging. The topic step is the only one the checklist can finish itself, and the only proof that counts is a phone buzzing, so there is a test push. POST /api/me/notify/test publishes directly rather than through the outbox, which requires an incident this deliberately does not have. Its failure is the useful part: a wrong topic, a rejected token and an ntfy that is down all look identical from the phone, which is silence, so the error comes back to the browser instead. Verified against a live server with a real ntfy stand-in, the whole path: an owner mints an invite, the sign-up page reports it valid and names the team, the invitee signs up and is signed in as a member of that team, the checklist's four questions answer correctly on a fresh install, a test push is refused with no topic and delivered with one -- "PAGED terdut-owner | terdut test" -- and the dismissal survives a reload. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-21 10:47:15 +02:00
Niklas Ye	d728af53b1	Put a team's own settings in the web UI ... Closes #17. Everything a team owner configures was API-only: escalation, integrations, dead man's switches, membership, and the rota -- which the on-call view still described as the TUI's job, and the TUI has been broken against this server since teams landed. Setting up the feature this whole line of work exists for meant using curl. A Team tab now holds all of it, one team at a time, with a picker for somebody in more than one. An owner edits; a member sees the same page without the controls, because the server refuses their writes anyway -- hiding a button is a courtesy to the reader, not the thing enforcing anything. The escalation editor holds a draft and sends the whole ladder, because the API replaces it wholesale: the levels are an order, and patching one rung leaves the numbering of the others undecided. Adding a level defaults to five minutes and the rota, which is the shape almost every ladder starts as. An integration key is returned exactly once, so creating one opens a panel that says so, shows the URL large with a copy button, and renders the Alertmanager receiver snippet with the URL already in it -- the next thing anybody does with that key is paste it into a config. The panel stays until it is dismissed rather than disappearing on the next re-render. The incident view gains where an incident is on the ladder and when the next page is due, which is the question somebody looking at an unacknowledged incident actually has. The API carries it: the incident payload now includes escalation_level and escalation_due_at, the latter computed in the incident SELECT by joining the level's timeout, so a list costs no extra queries. Verified against a live server by making every call the page makes, including the writes: the six reads the Team tab issues, a two-level ladder saved and read back, an integration created and its key returned once, three days of rota assigned, switches set, and an incident showing level 1 with a due time five minutes out. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-20 21:22:24 +02:00
Niklas Ye	b0a02c010b	Add an admin page, and move the behaviour settings into the database ... Closes #5. Three of the server's tunables were environment variables, which meant changing how long an incident waits before being paged again required editing a chart, merging it and waiting for a reconcile. They are behaviour rather than infrastructure, and the difference is who needs to change them and how often. The split is by who owns the value. What stays in the environment is where the server is plugged in: the listen address, the DSN, the ntfy URL and token, the public URL. Those are needed before the database is open and two of them are credentials -- the settings endpoint reports that ntfy is configured and that a token is set, and never what either is. What moves is how it behaves: the notify repeat interval, the stale window and the archive window. The environment variable becomes the seed rather than the setting, written once on first start and never overwritten, so a redeploy cannot put a chart's default back over an administrator's edit -- the rule the per-team dead man's switches already follow. The loops read the current value per tick, so a change at 02:00 is obeyed at 02:00. Key/value rather than a column per knob: #6 and #7 will both add settings, and a table shaped one-column-per-setting needs a migration for each. The cost is that values are text and the accessor has to say what type it wanted, which settings.go does in one place. Unknown keys are refused rather than stored -- a typo that wrote notify_repeat_second would otherwise sit in the table looking like configuration and doing nothing -- and each value has bounds loose enough to catch a slipped decimal point without having an opinion about anybody's rota. Disabling an account is new, and is not deleting one. Deleting a user nulls acknowledged_by and assigned_to, which quietly rewrites who did what during an incident months after the fact. A disabled user cannot authenticate by either credential, loses their sessions immediately, and stays the name on every acknowledgement they made. The check is part of the lookup in serveAs rather than a test afterwards, so there is no path where the row is loaded and the flag is then forgotten. The page itself is a fourth tab, shown only to an administrator and only as a courtesy: every endpoint under it is refused with 403 regardless, so somebody who types /admin gets an explanation rather than a blank screen. It lists teams with their size and open-incident count, users with their flags, and the settings with their bounds -- plus the environment half, read-only, so somebody hunting for the ntfy URL learns where it lives instead of concluding the server has none. Delete is disabled rather than offered-and-refused for a team with open incidents, and neither admin action is offered on your own account, since the server refuses both. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-20 18:23:46 +02:00
Niklas Ye	74359c72ab	Give each team its own dead man's switches, and the UI a team to show ... The rest of #4. Two halves that belong together because they are the same sentence from opposite ends: a team decides which of its alerts are heartbeats, and the UI has to be able to say which team it is talking about. Switches were three environment variables, which made them one setting for the whole install. That was the last piece of the alerting path a team could not control: it could take its own alerts on its own key and still not say which of them were heartbeats, or how long a silence had to last. They are a row per team now, edited by an owner through PUT /api/teams/{teamID}/deadman, and the sweeper runs each team against its own matchers, timeout and severity. The environment variables become the starting point rather than the setting. Every team without a configuration is seeded from them at startup, so an upgrade keeps watching exactly what it was watching, and SeedDeadmanConfigs never overwrites -- a redeploy must not put the environment's value back over an owner's edit. A team created later watches nothing until somebody says otherwise: inheriting an install-wide heartbeat would page a new team about a source it has never heard of, and a switch nobody chose is the kind that gets muted rather than fixed. A matcher string with no alertname in it is refused at the door instead of stored. Storing it would produce a switch that watches nothing silently, which is the exact failure the feature exists to prevent. NewRouter and Sweep lose their DeadmanConfig parameter -- there is no longer one answer to hand them. The type stays, because parsing a matcher string is still parsing a matcher string. The UI side: rows in the queue carry a team badge, the filter row gains a team chip per team, and "on call now" shows one card per team. All three appear only when the viewer is in more than one team -- otherwise they are the same word repeated down a list, which is noise rather than information, and the single-team install reads exactly as it did before teams existed. Verified against a live two-team server as well as in tests: the combined queue labelled by team, the team_id filter, a heartbeat that is a heartbeat in one team and an ordinary alert in another, and a new team's switches starting empty while the upgraded team keeps the environment's. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-20 15:18:22 +02:00
Niklas Ye	a4fbd60441	Scope everything to a team, and route alerts by integration key ... The core of #4, and what #1 is for: terdut stops being one shared space. A team owns its incidents, alerts, schedule and integrations; a user sees exactly the teams they are in. Everything that existed moves into one Default team and every existing user becomes an owner of it, so the upgrade is a no-op for the people using it. Ingestion is the load-bearing half. An alert arrives on a team's integration key, and the key is both the credential and the routing: it says that the sender may post, and which team the alerts belong to. That also closes the unauthenticated webhook -- the old path stays for one release, deprecated and routed to the oldest team, so an upgrade does not stop delivering while somebody edits the Alertmanager config. Scoping is enforced in as few places as possible, because the failure mode is silent. serveAs loads the caller's memberships once; list queries carry `team_id = ANY(...)`; and every incident route goes through incidentIDParam, which now parses the id AND checks the team in the same call, so a new handler cannot remember the first half and forget the second. Anything in another team is 404, never 403: whether an incident exists is that team's business. Two bugs this found, both of which would have been silent: * upsertAlerts decided "is this a new occurrence" by looking up the fingerprint alone. Across teams that made team B's first alert look like a re-send of team A's, so it opened no incident at all. The lookups are keyed on (team_id, fingerprint) now, as the index is. * Every uniqueness rule was written for one tenant. Two teams watching two clusters legitimately see the same fingerprint, the same groupKey, and want somebody on call on the same day; all three constraints move to include team_id. Roles inside a team are separate from the system administrator flag: an owner configures the team, a member works its incidents, and an admin is NOT implicitly in every team -- administration is about accounts, not about reading other people's incidents. An admin can still repair a team whose owner has left, which is why requireTeamOwner lets them through. A shift can only be given to somebody in the team. Paging a person who cannot open the incident is worse than paging nobody. The UI is updated only as far as keeping it working: it loads the viewer's teams with the session and uses the first one, since nobody has a second yet. "On call now" shows every team the viewer is in, named only when there is more than one, so the common case reads exactly as before. The team switcher, badges and per-team settings pages are the next step. Breaking for API clients: the schedule endpoints moved under the team, and /api/schedule/current returns an array rather than an object or a 404. terdut-tui will need a version for that. Per-team dead-man configuration is deliberately not here. A heartbeat's incident already opens in the team whose key received it, which is the part that matters for isolation; moving the matchers out of env into per-team rows is a change to how deadman.go is configured rather than to who sees what. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-20 13:36:24 +02:00
Niklas Ye	dc3879eca6	Serve a web UI for the incident queue, built for phones ... Whoever is on call gets paged on a phone, and until now the only ways to act on a page were the notification's Acknowledge button or a terminal. Tapping the notification itself opened /api/incidents/{id}, which a browser can only answer with a 401 in JSON. The server now serves a web UI at / covering the incident queue, each incident's alerts and timeline with every action on it, who is on call, the alert feed, and changing your own password. The notification link now points at /incidents/{id} in that UI. It is embedded in the binary and has no build step: plain HTML, CSS and ES modules under internal/web/static, served with an ETag per file and a CSP that allows nothing from any other origin. That is how rd-web is built. It avoids adding a node toolchain to the Dockerfile and the pipeline for a page this size, and it keeps the page on the same origin as the API, so no CORS is needed and nothing else has to be deployed. Paths without a file extension fall back to index.html, so a deep link survives a reload. An unknown path under /api/ still gets a JSON 404 rather than the page. Signing in uses a username and password, because pasting a 64-character API key into a phone at 3am is not a sign-in flow. Users have no password until one is set through PUT /api/users/{id}/password, or optionally at bootstrap. A user without a password is exactly where they were before this commit and can only use API keys. A login sets an HttpOnly, SameSite=Lax session cookie. It lasts 30 days and slides forward while in use, so an on-call phone does not sign itself out. Only the token's hash is stored, as for API keys. The cookie needs a CSRF guard where a bearer header does not, because browsers attach cookies to requests other sites make. So cookie- authenticated requests go through Go 1.25's http.CrossOriginProtection, and bearer requests do not. A request carrying an Authorization header is judged on that header alone and never falls back to the cookie. Changing a password ends every other session of that user. Changing your own requires the current password, so a phone left signed in cannot be used to take the account over. Failed logins are counted per username and per client address. Ten failures for one username in 15 minutes refuse that username for the rest of the window, even with the right password. That makes locking somebody out possible for anyone who knows their username. It was accepted because the alternative is unlimited guessing, and during a lockout the notification's Acknowledge button and API keys keep working. The address limit reads the first X-Forwarded-For hop, since behind the gateway RemoteAddr is Envoy. It is looser, because a whole office behind one NAT shares it. The Secure flag follows TERDUT_PUBLIC_URL, since TLS terminates at the gateway and the server itself only ever sees plain HTTP. The chart already defaults that variable to https://<hostname>. Schedule editing, statistics and user management stay in terdut-tui for now. The API they use is unchanged, and bearer authentication behaves exactly as before.	2026-09-19 17:48:21 +02:00