Approval Workflow

When editing is a team activity, publishing should include a second pair of eyes. Chinaski’s approval workflow (off by default, switched on in Settings → Workflow) makes editors submit work for review instead of publishing directly; an admin approves it — which publishes it live — or sends it back with a note. This page explains the review cycle for pages and posts.

Turning it on

Under Settings → Workflow:

• Check Require approval before editors can publish.
• Optionally set a review notification email — the address that gets a note each time something is submitted (with the submitter’s name, the title, and a direct edit link).

Admins are exempt by definition: they always publish as themselves.

The life of a page or post under review

1. Editor writes. Every item starts as a draft with the familiar editor and preview.
2. Submit for review. When an editor clicks Publish (with approval required) — or presses the Submit for Review button — the item goes to Pending review. It is not live on the site yet, and the flash message says exactly what happened: “Your changes have been submitted for admin review before publishing.” Any previously rejected item can be resubmitted after edits.
3. Admin decides. On the edit screen the admin sees Approve and Reject buttons (shown only where they apply):
   • Approve publishes the item for real: the review badge turns green (Approved), the content goes live, and the site rebuilds automatically. For posts, a first-publish date is stamped at approval time. A stale future schedule attached to the item is cleared so it can’t linger later.
   • Reject returns the item to the author as Returned, with an optional reason. It stays unpublished and shows up on the author’s edit screen as rejected, ready to be revised and resubmitted.
4. Everyone’s told. The creator receives an email either way — “approved” or “returned for revision” with the reason — provided their account has an email address (handled by the notification setting’s SMTP configuration). Every submit/approve/reject is recorded in the audit log with who, what, and which item.

What editors experience

• There is nothing to install: the Publish button itself becomes “submit for review” — the editor sees the submission confirmation immediately.
• Editorial “publish now” from the calendar or a bulk publish behaves the same way (review submission) — editors never bypass the gate.
• Bulk operations respect the rule too: selecting several pages and clicking publish submits each pending/rejected page for review (and admins still just publish).
• The editor’s Status box shows the workflow chip alongside the live/draft badge: Draft · Pending review · Approved · Returned — so at a glance you know where an item stands.
• The “already pending review” protection: an item can’t be submitted twice; admins approve once and the badge settles. Resubmission from a rejected item is of course allowed after edits.

What reviewers get

• The direct Edit link in the submission email — click to open the item.
• The usual Preview controls (history, drafts) apply before approving.
• Approve = go-live: the button publishes and dispatches the site rebuild in one action, so “approved” means readers can see it.
• Reject takes the title plus an optional reason (which is emailed and recorded) and hands the item back.

Who reviews whom

• Admins review everything — there is one decision layer (no intermediate reviewer roles).
• Items in review are not drafted in someone else’s queue: any admin sees the pending item in the normal pages/posts lists and the content calendar, so “who’s waiting?” is answered by the standard content screens, not a separate dashboard.
• Schedules: an editor submitting an item that had a future publish date keeps that plan intact — but if an Approve arrives after scheduled pub time has been cleared during review, the approval publishes immediately (the code clears any stale schedule so approval doesn’t attach a surprise future time).

The fine print

• The switch applies to pages and posts; blocks, snippets, and other structurals have their own publishing rules (they’re less visible on the face of the site). Document versions have a separate, independent review pipeline in the Documents module.
• The workflow protects against accidental or unauthorized publishing, not censorship: admins keep full direct-publish ability, and every decision is audit-logged either way.
• Reviewer notification emails are optional; the workflow works without them (the admin sees pending items in lists; “submitted for review” appears in the audit log).
• If you approve a page that was submitted while a future publish date was still set, publishing happens at approval — the future date is cleared rather than left behind.

The short version

Flip the switch, and “publish” for editors becomes “submit for review” — admins approve (publish + rebuild in one step) or reject with a note, the audit log records both directions, and nobody has to trust good intentions alone.