Governance · 11 / 23
Publication protection
A content type can require a number of approvals on the current version before anything of that kind goes live.
Fields marked * are required before this entry can be published.
Every check passes — ready to publish.
This type is protected: publishing needs 2 approvals on the current version.
Enough approvals on this version — Publish is unlocked.
approved version 6 — the entry has changed since, so this no longer counts
approved version 6 — the entry has changed since, so this no longer counts
How it works
- 01
An administrator sets a rule per content type, for example two approvals.
- 02
Request review from named people. Each approves the version.
- 03
Saving starts a new version, and the count starts again.
- Rules
- Per content type, 1 to 100 approvals
- Counted on
- The current version only
- Authors
- Cannot approve their own version
In depth · For editors-in-chief and auditors
Four eyes before it goes live
Switch protection on for a content type and publishing needs approvals on the current version, from somebody other than its author.
One gate for every way to publish
The rule sits on the publish path itself, so it covers the editor’s button, REST, GraphQL and agents over MCP alike. A refusal is a 409 that says what was required and what was given.
Three callers — an editor, an API token and an agent — arriving at one rule demanding two approvals on the current version, with publication behind it.
Approvals belong to a version
An approval is recorded against the version it was given on. Save again and the count returns to zero, so nobody publishes text that nobody read. Translations are versioned per language, so each is approved on its own.
What a rule says
Show the table
| Setting | What it decides |
|---|---|
| Enabled | Off by default; off behaves like no rule. |
| Required approvals | How many the current version needs. |
| Require somebody else | On by default: authors cannot approve their own version. |
| Count stale approvals | Off by default: earlier versions’ approvals do not count. |
| Administrator bypass | On by default, after a confirmation that is logged. |
| Allow token publish | Off by default: a token names no person. |
Changing a rule is itself written to the activity log.
Around the edges
- A bypass is logged
- An administrator publishing short of approvals confirms first, and the activity log names them and the rule.
- No agent can approve
- There is no approve tool for the assistant or over MCP; agents can only ask people.
- Readers never see it
- Review state is never returned as a status, so APIs, exports and webhooks are unchanged.
- Off until you write a rule
- With no rule, publishing behaves exactly as it does with the plugin uninstalled.
Questions
Is this an editorial workflow?
No. There are no stages and no new status: entries stay draft or published. A rule gates one transition and comes off as easily as it went on.
Who is allowed to approve?
Anybody in the workspace holding content:approve, except the author of the version being published.
What happens in a one-person workspace?
A rule requiring somebody else blocks everything, so the settings screen warns you when you switch it on.