94fb6ac53c
Every write in TicketingSettingsController is requireManagerAccess() — an existing manager of that exact group, or 403 — and settings.agents.store, the only route that writes a `ticketing_agent_access` row, is gated the same way. storeGroup() auto-appoints a manager only for a group it creates. So the moment a group's last manager stopped being able to act, the group froze for good: no rename, no archive, no delete, no project, no agent, and no ticket in it ever assigned, worked or closed. The page's own answer on the Agents tab was "Ask a manager of the group to add you", which on such a group names nobody. On dev that was every group: all 15 held exactly one agent row, the same person on every one, and that account had been rewritten into an admissions-only applicant (#4202/#4203) and could not reach /app/ticketing at all. Fifteen groups, fourteen tickets, nobody who could administer any of it, and nothing a super admin could press — the "ticketing lifecycle is DEAD on dev" observation of 2026-10-18 is this, not a seed gap. One carve-out, and no more: a site admin may write an agent row for a group that has NO manager left who could still use this page. "Still" is the operative word and canStillAdminister() is its definition — the account must exist, be active, and hold `ticketing.settings`, which is exactly what the route itself demands, so it answers "could this manager have done this write themselves". A manager row outlives all three. #4710's rule is untouched: the carve-out is a property of the GROUP, not of the caller, so a group somebody is still running remains none of an admin's business, and the rescue grants the rescuer nothing beyond the row they wrote — appoint somebody else and the very next request is refused again. The page gets `orphanedGroupIds` so the Agents tab can offer the recovery, label those groups "— no manager", and explain what appointing one does (shell side). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>