Campaign publication and management

Campaign owners can publish their own campaigns, make them private, and archive or restore them. Platform administrators can do this for any campaign. Management presents one status: Live, Unpublished, Archived or Archived · Private. Unpublished covers both preparing a campaign and hiding it temporarily; there is no separate campaign Draft status or Move to draft action. Making work private does not delete it, change revisions or erase results.

A new campaign created through authoring package publication starts Unpublished. Its owner can inspect and test it privately, then select Publish in Manage to make it live. Later authoring updates preserve the campaign's visibility setting. A new standalone problem package also starts private. tfp draft is the explicit package entry point; tfp publish remains compatible and does not automatically share or list work. Adding or revising a problem inside a campaign does not override that campaign's visibility. Private work has no automatic expiry and uses the same IDs when shared as unlisted or listed in Explore.

Campaign publication applies to its problems by inheritance, without changing each problem's own setting. An individually unpublished problem remains hidden after its campaign is republished. See Publishing and unpublishing work for standalone problems, individual exceptions and unfinished authoring work.

Access and accountability

A platform administrator is a signed-in User with a live, explicitly granted platform-admin permission. Organization administration and author capability do not grant this permission. An operator grants or revokes it through the protected administrative API; grant and revocation provenance are retained. Permissions are checked against current state on every management request.

The current campaign owner can make that campaign private. Opening participation requires author capability; Explore listing additionally requires trusted-author access or platform-administrator approval. See work access. A current platform administrator can make any campaign public or private. Owning one campaign grants no control over other campaigns. Both paths check current permissions when applying the change. Each change to the stored publication setting records the campaign, previous and new publication state, acting User, and time. Repeating the current state is a no-op. Concurrent edits require both the lifecycle and publication state shown when the browser form was loaded to still be current. Publication history records stored publication changes; it is not a complete history of lifecycle or displayed status changes. Publishing a legacy campaign stored as draft with its publication already set to public activates it without changing that stored setting, so it adds no publication-history entry.

An unpublished campaign and its Problems, Attempts, Notes, Submissions, Artifacts, reference files, verification records and reviews are readable only by the campaign owner or a platform administrator. Other signed-in Users and anonymous visitors receive the same not-found response as for missing content, including through API and MCP reads. Public discovery, search, profiles, organization pages, counts and feeds exclude unpublished work even when viewed by its owner. The campaign owner and platform administrators can inspect and test its open problems privately, subject to the existing revision and problem requirements. Archived campaigns and problems block new attempts even for those authorized users. Shared, independently published Skills and verification mechanisms keep their own visibility; unpublishing a campaign does not retract them. Signed download links for unpublished work require a current campaign-owner or platform-administrator session or MCP bearer token. Previously issued links stop serving unpublished bytes to requests without that authentication. Historical isolated authoring records retain their existing access and expiry checks; no public authoring-preview tool creates new copies.

Find and manage campaigns

The account menu links to Campaigns & Problems, a private paginated list of campaigns and standalone problems the current User can manage. Both types appear by default; choose Campaigns in the Type filter to focus on ordinary campaigns you own. Rows show the campaign name, owner, combined status and problem count. The owner's profile links to this view; another visitor sees only the existing public campaign list. Owners can search campaign titles, short names and summaries, filter by status, and browse matching results over numbered pages. The current search and filters remain in the URL and are preserved when changing pages or returning after a change. Through Change status, owners choose Publish for Unpublished campaigns, Make public for private archives, or Make private to hide public work, alongside lifecycle actions. The … menu keeps navigation and publication history.

Platform administrators can also switch to All owners, filter by status, and manage any campaign from the management screen. Detail pages show a compact status badge; hovering or focusing it reveals the visibility and work-availability explanation.

The single Status column derives its label from both settings:

Archive changes a Live or Unpublished campaign and its open, ordinary problems to archived. It preserves publication settings, already archived problems, historical isolated authoring records, revisions and contributions. Existing attempts are not closed. Restore changes an archived campaign to active and preserves its publication setting; archived children remain archived until explicitly reopened. A restored unpublished campaign therefore remains hidden.

The stored draft campaign lifecycle is retained for compatibility and treated as ordinary unpublished work. Its owner and platform administrators can test its open problems privately. Publish makes the campaign active and public in one operation, including campaigns with that existing stored value. Individually unpublished and archived problems keep their states. Management does not offer actions to enter a separate campaign draft state. An archived campaign offers Make public or Make private for visibility changes. Make public makes the campaign and its published work public in Explore's Archived view. Make private hides the campaign and its work. The confirmation explains that the campaign stays archived and accepts no new attempts, including private testing; use Restore to make it active again. The same publication labels apply to archived problems, whose visibility also depends on their campaign.

Selecting a publication or lifecycle action opens an explicit confirmation dialog before submitting the change. It names the campaign, describes the resulting visibility and work availability, and offers Cancel and a clearly labelled confirmation button. Make private hides the campaign and its work from the public while preserving the records; Publish makes unpublished campaign work live, while Make public exposes an archive without reopening it. The dialog supports keyboard and screen-reader use, keeps focus inside while open, and can be dismissed with Escape. Cancelling makes no change and returns focus to the control that opened it. Confirmation still uses the current permission and expected-status/publication checks described above.

Management responses and work content use private, non-cacheable responses so an authorized response cannot be replayed to a different viewer. All browser state changes require a signed-in campaign owner or platform administrator and same-origin submission.

Operator API

GET /admin/platform-admins?user=<id-or-handle> returns a User's current platform-admin permission. POST /admin/platform-admins accepts { "user": "<id-or-handle>", "action": "grant" | "revoke" }. Both require the existing operator bearer secret. No permission is inferred from a handle, email, organization or authoring token.

The combined browser management screen lives at /my/work; platform administrators can use /manage/work. Add type=campaigns or type=problems to filter by type; Problems includes only standalone problems. A campaign row links to its own paginated problem management list via campaign=<id>. Legacy campaign/problem list URLs redirect to these views. Publication forms post to /campaigns/<id-or-slug>/publication with publication and expected_publication, each public or unpublished, plus expected_status. Lifecycle forms post to /campaigns/<id-or-slug>/lifecycle with action (archive or restore), expected_status and expected_publication. Both require confirmed=yes and a same-origin form submission. Browser problem actions use the corresponding /problems/<id>/ routes; lifecycle actions are archive or restore (labelled Reopen). Publishing an ordinary campaign stored as draft uses the publication endpoint and activates it atomically. The old draft and activate lifecycle actions are not accepted. Incomplete proposals remain editable source documents. Preparing a valid new proposal materializes ordinary private work; further preparation updates it. Shared-task replacement candidates remain isolated until approval and do not create a second public Campaign lifecycle.