eb198ab05a
The Groups, Agents and Projects tabs were scoped to the viewer's `ticketing_agent_access` rows. A site admin holds none of those, so the lists came back empty and the Vue — which decided between "first run" and "nothing for you" on list length alone — rendered the first-run copy: "No groups yet. Create your first group above.", on a page whose own props said `isBootstrap: false` and `isSiteAdmin: true`. The two empty states on that page contradicted each other and the one that won was the one inviting a duplicate of a group that already existed. On dev that was the normal case, not a corner: every pre-existing group had zero agent-access rows, so the whole configuration was invisible to the one role meant to own it. The list is now what this page is for: a site admin sees every group (archived ones included, as before), agent, project and email connection. What they may DO is unchanged — requireManagerAccess() still gates every write per group, which is what GroupRetirementTest already demanded of exactly this user. So the page also ships `myManagedGroupIds`: the rows a viewer cannot act on say "Not yours to manage" instead of offering an Edit that 403s, and the add-agent / add-project group pickers offer only groups the viewer manages. Known and deliberately left: a group with zero agent-access rows is still frozen — adding its first agent needs a manager row on it, which nobody holds. It is now visible and labelled rather than invisible, but thawing it is a separate decision (operator notified). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>