[Frontend] Admins should be able to see every campaign from the admin panel #437
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
An instance admin has no way to see the campaigns on their own instance. Campaign visibility is scoped to membership, so an admin sees only the campaigns they happen to belong to — the admin panel has no campaign view at all.
Why it matters
Every admin surface that touches a campaign already assumes you can identify one. The recordings/trash list, retention overrides, and audit entries are all campaign-scoped, but there is nowhere to answer "what campaigns exist on this instance, and who runs them".
It also blocks ordinary operator work:
guild_id/ notification channel when bot routing misbehaves, which today needs database access.Found while working on dev: a restored database left the operator's login on a user row with no memberships, so the instance appeared to have no campaigns at all. There was no way to tell from the UI whether the campaigns were missing, hidden, or simply not visible to that identity — that took a SQL query to establish. An admin campaign list would have answered it immediately.
Suggested shape
A read-oriented list in the admin panel: name, GM(s), member count, session count,
guild_idpresence, retention overrides where set, created date. Enough to identify a campaign and reach it, not a second campaign-management UI.Worth deciding explicitly as part of the design work:
Acceptance criteria
Related
Picking up the backend half now (#535 phase 4); the admin-panel screen follows in the rebuild's last lane.
The decision the body asked for, taken explicitly: metadata only. An admin sees that a campaign exists, who runs it, how big it is, whether it is linked to Discord, whether delivery is failing, and which retention overrides it carries. An admin does not open a campaign, and the endpoint returns no campaign content. If a drill-through is ever wanted it is a separate issue with an audit entry, as the body suggests.
Shape:
GET /api/admin/campaigns, admin-only, every campaign regardless of membership, soft-deleted ones excluded unless?include_deleted=true, counts done in SQL, two-GM campaigns visible throughgm_count. No migration.Backend half done in PR #538 (auto-merge armed); this issue stays open for the admin screen, which lands in the rebuild's last lane (#535 phase 5b).
GET /api/admin/campaigns, admin-only, every campaign regardless of membership, case-insensitive name order with the id as tie-break. Per row: id, name, game system, GMs in join order,gm_count, member and session counts,has_guild,has_notification_channel,discord_delivery_failing(only when the bot's last word wasfailing; untested reads as false),retention_overrideswith only the fields set,is_archived,created_at,deleted_at; soft-deleted campaigns excluded unless?include_deleted=true.The content-access decision is written into the code and
docs/API.md: metadata only; no drill-through. A test asserts the exact key set and greps the body for seeded secrets (description, webhook, invite code, share token). Two queries regardless of campaign count, pinned by a statement-counting test. Two judgment calls recorded in the PR:session_countincludes cancelled sessions; response models sit inline inadmin.pyas that file's other models do. Full suite 2,516 passed, +12.