4 Commits

Author	SHA1	Message	Date
Niklas Ye	a6fa673e08	Give every team a page of its own ... The Admin tab's team list was growing controls the way the user list did before ac9af8e: a Rename button behind window.prompt, a Delete beside it, and -- on the Users page, of all places -- an invite form with a team picker in front of it. The picker was the admission that an invite is a fact about a team rather than about the server, and a prompt() is the wrong place to read a 409 about a name already taken. So a team is now a subject with a page, at /admin/teams/{id}, the mirror of /admin/users/{id}: when it was created, how many are in it and how much is open, a field to rename it, the members with their roles, the invites into it, and deletion. The list goes back to being a list, and the name in it is the way in. The member list is the one thing there that needed a new endpoint. GET /api/teams/{id}/members is requireTeamMember and answers 404 to an administrator who is not in the team, and that stays exactly as it is: member means membership and nothing else. Reading a team's shape is a different question from reading its work, so it gets an endpoint of its own under AdminOnly -- GET /api/admin/teams/{id}, returning {"team", "members"} -- rather than an exception carved into that rule. It is a wrapper and not a team with the members hung off it, because "members" already means a count on the list endpoint and one name must not be a number in one answer and an array in the next. The query and its ordering are copied from handleListTeamMembers so the two answers to "who is in this team" cannot disagree. An administrator still sees none of that team's incidents, alerts or rota. Nothing about what the flag may do changed; it could already rename and delete any team, and staff one it is not in. Rename now trims what it is given, as creation has always trimmed. Before this, " " was a legal name to rename a team to but not to create one with, which is one rule stated twice and applied once. Nobody has looked at this in a browser, the caveat ac9af8e and 07914d5 both carried. What is checked is the wiring: admin_test.go covers the new endpoint for an administrator outside the team, the 404 the member-only endpoint still gives that same administrator, the 403 for a member who is not one, a 404 for a team that does not exist, a 400 for an id that is not a number, and the trim; the module graph evaluates at /admin/teams/{id}, and the server serves index.html there, so a reload survives. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-22 09:13:13 +02:00
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	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	1377d9005b	Add a system administrator role, and gate account management behind it ... Until now every authenticated caller could create and delete users, set anybody's password and mint anybody's API keys -- auth.go said so in a comment. Defensible with one operator and a hand-made account; not once people sign themselves up (#7), and not in a multi-tenant install (#4), where the user list is no longer everybody who works here. users.is_admin is the flag. AdminOnly gates creating and deleting users and granting the flag itself. The endpoints that are self-service for your own account and administration for somebody else's -- password, ntfy topic, API keys -- go through requireSelfOrAdmin instead, because which rule applies depends on the {id} in the path rather than on the route. Minting your own API key stays self-service. A key carries exactly the rights of the user it belongs to, so issuing one is no more than signing in again; requiring an admin for it would mean a responder cannot set up the TUI without somebody else in the room. /api/users stays readable by everybody. The queue's assignment control and the on-call schedule both have to name people, and hiding the roster from the people on it buys nothing. THE MIGRATION MAKES EVERY EXISTING USER AN ADMINISTRATOR. They already hold these powers, so nobody's access changes on upgrade: it names what is already true and leaves demotion as a deliberate act. Promoting only user 1 would silently strip the others, and could leave an install whose only administrator is an account nobody has a password for. Two guards keep an install administrable: the last administrator can be neither deleted nor demoted, and nobody can delete or demote themselves -- the likelier accident, where the only admin clears their own flag while tidying up and locks the door behind them. No UI changes: there are no account-management screens yet. models.User carries is_admin (not omitempty, so a client can tell false from an old server), which is what #5's admin page will render from.	2026-09-20 13:20:04 +02:00