Delete a team and unroute its tickets, on the record
Remove a team and record what that did to its tickets.
/v1/teams/{team_id}Admin- Operation id
- delete_team
- Access
- An editor or a viewer is refused.
/v1/teams/{team_id}Remove a team and record what that did to its tickets.
tickets.team_id is ON DELETE SET NULL, so the delete unroutes every
ticket the team held. Before FR-80 that happened with nothing written
anywhere: a week later an unrouted ticket is indistinguishable from one that
was never routed, and the routing rule an operator is looking for is a row
that no longer exists. Each affected non-terminal ticket therefore gets an
assignment event naming the team that went away and the admin who removed
it, with the same event kind and team_from/team_to shape a routing change
already writes, so the timeline has one vocabulary for "this ticket moved"
rather than two.
The ticket ids are read before the delete, because after it there is nothing left to join to.
Non-terminal tickets only. FR-80 says "every ticket the deletion
unroutes", and this deliberately does less than that sentence. Read it
before changing it back. ON DELETE SET NULL unroutes solved and closed
tickets too, so the literal reading writes an event on every one of them:
an unbounded write inside a single transaction, worst on precisely the
workspaces that have been running longest, to say something about tickets
nobody will route again. AC-91 asserts the non-terminal set and FR-80's own
confirmation clause counts the non-terminal set, so that is the section's own
notion of which tickets this deletion affects. It is the set written here and
the set deletion-impact reports, and the two are one query so they cannot
disagree.
Tenancy: the request is scoped to one workspace, and the credential presented is what selects it. A caller with no membership in that workspace is refused with 404, which is indistinguishable from a workspace that does not exist.
Authorisation: admin or owner. An editor or viewer receives 403 insufficient_role.
Access: Authorization: Bearer carrying either a realm access token or an API key. A key must hold the helpdesk-ops:write scope, and the workspace role of the person who owns it must meet the floor above.
A realm-issued access token, presented as Authorization: Bearer <token>. It acts as the person who signed in, and every operation resolves their workspace role live from the membership record.
In: header
Path Parameters
uuidResponse Body
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/v1/teams/497f6eca-6276-4993-bfeb-53cbbbba6f08"