ROKRescue Operator Knowledge

Reference

Approval policies

Make two-person sign-off automatic — require one to three approvers for every item of a content type, every item carrying a tag, or everything inside a guide.

Settings → Approval policies is where you write the rules that make two-person sign-off automatic. Open it from Organization → Settings, then the Approval policies card.

Without a policy, an item needs sign-off only when a publisher ticks Required on that item's Two-person sign-off card. A policy states the rule once — "everything under Water Rescue needs a second approver" — and the database applies it to every item that matches, now and in future.

What sign-off means, why approvals expire when the words change, and why one person cannot push a gated item through alone are explained in How two-person sign-off works. This page covers the screen.

The policies table

ColumnShows
PolicyThe name you gave it. A policy that is switched off is dimmed and carries an Off badge
Applies toWhat it matches: every item of a type, items tagged with a named tag, or items inside a named guide "(and its sub-guides)"
ApprovalsHow many distinct approvers it demands
ActionsTurn off or Turn on, and a delete button

With no policies, the table reads "No policies yet. Sign-off is required only where someone ticks it on the item itself."

Create a policy

Select New policy. A form opens above the table.

FieldWhat to enter
NameA name people will recognise when the editor tells them why sign-off is required
Applies toContent type (every item of one type), Tag (every item carrying a tag), or Guide (everything inside a guide, including its sub-guides)
Content type / Tag / GuideThe target. Only the picker for the chosen kind appears. In the guide list, sub-guides are indented with a dash
Approvals required1 to 3 — distinct approvers, excluding the author and whoever publishes

Select Create policy. The form closes, "Approval policy created" confirms it, and the policy starts applying immediately. Cancel discards the form.

If something is missing, the page says what: "Give the policy a name.", "Pick a tag." or "Pick a guide."

A policy cannot be edited after it is created. To change its target or its number, create the replacement first, then delete the old one — doing it in that order leaves no gap in which matching items are unprotected.

What each kind matches

  • Content type matches every item of that type, including items created later.
  • Tag matches items while they carry the tag. Tag an item and it is covered at once; remove the tag and it no longer is.
  • Guide matches every item directly inside the guide and every item inside its sub-guides. The guide itself is not matched — only its contents. To gate a guide's own introduction, add a Content type policy for guides or tick Required on that guide.

Turn a policy off, on, or delete it

Turn off keeps the policy but stops it counting; the row dims and shows Off. Turn on restores it. Both take effect immediately.

The delete button asks you to confirm: "Items matched only by this policy will no longer require a second approval before publishing." Select Delete, and "Approval policy deleted" confirms it. Items still matched by another policy, or with Required ticked, keep their requirement.

How the required number is worked out

The database folds everything that applies to an item into one number:

  • each enabled policy that matches the item contributes its Approvals required;
  • a ticked Required box on the item contributes one;
  • the item needs the highest of those — they are not added together.

So two matching policies asking for 1 and 2 approvals require 2, and a ticked box on an item a policy already gates at 2 still requires 2. Turning a policy on can never weaken a requirement someone set by hand.

The item's Two-person sign-off card in the editor shows the result: a Required by policy box listing each matching policy and its number, and a badge counting approvals against the requirement on the current version. Approvers sign off from that card. See Content editor.

What the database enforces

The rules are checked by the database on every publish, not by this page:

  • An item whose requirement is above zero cannot be published until enough distinct people have approved its current version, none of them the author or the person publishing. The refusal says how many approvals the item needs and how many it has.
  • The publish itself must not change the title, summary or body — what is published is exactly what was approved.
  • Edits to a published item covered by a policy are allowed, but held: operators keep the released version. Release to operators sends the changes only once the current version has the approvals, from people other than the author and the person releasing: "These changes need N approval(s) on the current version, from people other than the author and the publisher — they have M".
  • A scheduled publish runs the same check when its time comes, counting the person who scheduled it as the publisher. An item short of approvals is not published; it stays in the Scheduled (opens the admin console) queue.
  • Approving needs the Second approval permission, and the database refuses an approval from the item's author.

Who can do what

ActionNeeds
Open this page; create, turn on/off, delete policiesManage settings — the database refuses anyone else
See which policies apply to an item in the editorAny permission at all (every staff member)
Tick or untick Required on an itemPublish — the database refuses anyone else
Approve an itemSecond approval

See also

Last reviewed