[Frontend] Admins should be able to see every campaign from the admin panel

claude-bot commented

2026-08-29 06:39:19 +00:00

Collaborator

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:

Diagnosing a report from a GM whose campaign the admin is not a member of.
Checking which campaigns have per-campaign retention overrides, now that those diverge from the instance default (#119, and more so after #427 changed what the default does).
Seeing that a campaign has two GMs — currently a latent 500 on the journal (#411) with no way to spot the condition ahead of a user hitting it.
Confirming a campaign's 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_id presence, 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:

Whether an admin can open a campaign, or only see that it exists. Campaign content is a table's private material — transcripts, notes, lore. "The admin can read every table's session notes" is a different product promise from "the admin can administer the instance", and this issue should not smuggle the former in. Listing metadata is clearly fine; a drill-through needs a deliberate answer, and possibly an audit entry when used.
Whether it belongs in the admin panel or as a filter on an existing campaigns view.

Acceptance criteria

An admin can see every campaign on the instance, regardless of membership
The list surfaces enough to identify and act on a campaign: GM(s), member count, guild linkage, retention overrides
Campaigns with more than one GM are visibly distinguishable (see #411)
A non-admin gains no new visibility
The decision on whether admins can read campaign content is made explicitly and written down, not left to fall out of the implementation
If content access is granted, it is audited

#411 — two-GM campaigns 500 on the journal; this makes the condition findable
#427 — per-campaign retention overrides now have materially different consequences, so seeing which campaigns set them matters more
#436 — the same dev-restore situation that surfaced this

## 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: - Diagnosing a report from a GM whose campaign the admin is not a member of. - Checking which campaigns have per-campaign retention overrides, now that those diverge from the instance default (#119, and more so after #427 changed what the default *does*). - Seeing that a campaign has two GMs — currently a latent 500 on the journal (#411) with no way to spot the condition ahead of a user hitting it. - Confirming a campaign's `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_id` presence, 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: - **Whether an admin can open a campaign, or only see that it exists.** Campaign content is a table's private material — transcripts, notes, lore. "The admin can read every table's session notes" is a different product promise from "the admin can administer the instance", and this issue should not smuggle the former in. Listing metadata is clearly fine; a drill-through needs a deliberate answer, and possibly an audit entry when used. - Whether it belongs in the admin panel or as a filter on an existing campaigns view. ## Acceptance criteria - [ ] An admin can see every campaign on the instance, regardless of membership - [ ] The list surfaces enough to identify and act on a campaign: GM(s), member count, guild linkage, retention overrides - [ ] Campaigns with more than one GM are visibly distinguishable (see #411) - [ ] A non-admin gains no new visibility - [ ] The decision on whether admins can read campaign *content* is made explicitly and written down, not left to fall out of the implementation - [ ] If content access is granted, it is audited ## Related - #411 — two-GM campaigns 500 on the journal; this makes the condition findable - #427 — per-campaign retention overrides now have materially different consequences, so seeing which campaigns set them matters more - #436 — the same dev-restore situation that surfaced this

claude-bot added this to the v4.5.0 - UX Overhaul: Design Exploration & Rebuild milestone

2026-08-29 06:39:26 +00:00

claude-bot referenced this issue

2026-08-29 18:03:43 +00:00

[Frontend] First-run setup wizard so nothing gets forgotten on a fresh install #439

claude-bot referenced this issue

2026-09-06 19:30:20 +00:00

v4.4.0 build order: UX Overhaul in six phases, with two review checkpoints #535

claude-bot commented

2026-09-06 19:48:14 +00:00

Author

Collaborator

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 through gm_count. No migration.

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 through `gm_count`. No migration.

claude-bot referenced this issue

2026-09-06 19:53:19 +00:00

v4.4.0 build order: UX Overhaul in six phases, with two review checkpoints #535

rbrooks referenced this issue from a commit

2026-09-06 20:04:01 +00:00

feat(backend): admin-only list of every campaign on the instance, metadata only (#437)

claude-bot referenced this issue

2026-09-06 20:04:20 +00:00

feat(backend): admin-only list of every campaign on the instance, metadata only (#437) #538

claude-bot commented

2026-09-06 20:04:40 +00:00

Author

Collaborator

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 was failing; untested reads as false), retention_overrides with 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_count includes cancelled sessions; response models sit inline in admin.py as that file's other models do. Full suite 2,516 passed, +12.

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 was `failing`; untested reads as false), `retention_overrides` with 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_count` includes cancelled sessions; response models sit inline in `admin.py` as that file's other models do. Full suite 2,516 passed, +12.

rbrooks referenced this issue from a commit

2026-09-06 20:28:05 +00:00

feat(backend): admin-only list of every campaign on the instance, metadata only (#437)

claude-bot referenced this issue from a commit

2026-09-06 20:45:16 +00:00

Merge PR #538: feat(backend): admin-only list of every campaign on the instance, metadata only (#437)

claude-bot referenced this issue

2026-09-06 21:03:12 +00:00

v4.4.0 build order: UX Overhaul in six phases, with two review checkpoints #535

claude-bot referenced this issue

2026-09-15 18:21:00 +00:00

[UX] Redesign coverage: where every shipped and planned feature lives in Design A #656

claude-bot referenced this issue

2026-09-22 00:12:26 +00:00

Build lane 9: Admin (ADMIN-1 to ADMIN-15) #735

claude-bot commented

2026-10-01 19:01:45 +00:00

Author

Collaborator

Closing: built, checked against main (acf3d1ea) on 1 Oct.

GET /api/admin/campaigns (routers/admin.py, list_all_campaigns, admin-only) returns every campaign whatever the caller's membership: owner and GMs, a count of GMs, members and sessions, whether a Discord channel is set and whether delivery is failing, any retention overrides, archived and binned state.
The screen is Admin → Campaigns (pages/admin/AdminCampaigns.jsx, lane 9), with a "N GMs" chip when there is more than one.
The content question was settled in this thread: metadata only, no way into a campaign. test_response_carries_no_campaign_content pins the exact fields and checks seeded secrets are absent; test_non_admin_is_forbidden covers everyone else.

Two small things noticed, neither part of this issue: the screen never asks for binned campaigns (include_deleted is not sent), so its "In the bin" label can't appear; and the screen has no frontend test of its own.

Closing: built, checked against main (acf3d1ea) on 1 Oct. - `GET /api/admin/campaigns` (`routers/admin.py`, `list_all_campaigns`, admin-only) returns every campaign whatever the caller's membership: owner and GMs, a count of GMs, members and sessions, whether a Discord channel is set and whether delivery is failing, any retention overrides, archived and binned state. - The screen is Admin → Campaigns (`pages/admin/AdminCampaigns.jsx`, lane 9), with a "N GMs" chip when there is more than one. - The content question was settled in this thread: metadata only, no way into a campaign. `test_response_carries_no_campaign_content` pins the exact fields and checks seeded secrets are absent; `test_non_admin_is_forbidden` covers everyone else. Two small things noticed, neither part of this issue: the screen never asks for binned campaigns (`include_deleted` is not sent), so its "In the bin" label can't appear; and the screen has no frontend test of its own.

claude-bot closed this issue

2026-10-01 19:02:12 +00:00

Rows
Columns

[Frontend] Admins should be able to see every campaign from the admin panel #437

What

Why it matters

Suggested shape

Acceptance criteria

Related