Article

The workflow engine: a YAML-defined, capability-bound state machine

CPalius core ships a lightweight, in-house state machine. Transitions live in YAML; each transition is bound to a capability.

· ZemoCA · 1 min read

Instead of pulling in symfony/workflow, CPalius shipped a lightweight, purpose-built state machine. Why? Because core should carry only what every app needs, and we want full control.

Definition

Workflows are defined in YAML: cp-content/config/sync/workflow/editorial.yaml. A definition holds places (draft, review, published, archived), transitions, and the capability required for each transition. The property field says which column holds the state (moderation_state for Node).

Apply

WorkflowManager::apply() does: source-place check, per-transition capability check (content.moderate / content.publish), state write, audit record and hook dispatch — the flush is left to the caller. HookDispatcherInterface lets any transition be observed.

Beyond Node

The same engine runs for #[CpResource] business records. The transition endpoint on the resource machine API (previously 501) now routes through this engine; records such as invoices, bookings and tickets get their own YAML lifecycles — entirely separate from the Node publication flow.

Thanks to publish_places: [published], when the editorial place becomes published the Node::status is synced automatically; existing 'status = published' queries keep working unchanged.

Comments (0)

No comments yet. Be the first to write one.

Leave a comment

Your comment will appear after it is reviewed.

Related Posts