The workflow functionality passes a Content item version through a series of stages.
For example, an editorial workflow can pass a Content item from draft stage through design and proofreading.
You can define different workflow in configuration. The workflow is permission-aware.
Each workflow consists of stages and transitions between them.
The following configuration defines a workflow where you can pass a draft to proofreading, and then to final approval.
The workflow is defined in the
config/packages/ezplatform.yaml configuration file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
Each stage in the workflow has an identifier and can be assigned a label and a color (lines 16-18).
Each transition also has an identifier. It must state between which stages it transitions, or be marked as
reverse of a different transition.
Transitions can also have labels, colors, and icons (lines 33-35).
If you don't define a custom color for a transition, a default setting will be used (
You can require that a reviewer has to be selected when content is sent through a transition (lines 36-37). The user will then not have the option to send the Content item without selecting a reviewer:
If a User does not have the permissions to view or edit the Content item, you cannot select them as a reviewer.
You can view all configured workflows in the Admin Panel by selecting Workflow.
Publishing content with workflow¶
You can automatically publish a Content item once it goes through a specific transition.
To do so, configure the
publish action for the transition:
1 2 3 4 5 6 7 8 9 10 11
When an editor selects a reviewer in the Back Office, your configuration can send a notification to the reviewer:
1 2 3 4 5 6 7 8 9
The notification is displayed in the user menu:
You can limit access to workflows at stage and transition level.
workflow/change_stage Policy to grant a User permission to change stages in a specific workflow.
This Policy can be limited with the Workflow Transition Limitation to only allow sending content in the allowed transition.
For example, using the example above, a
workflow/change_stage Policy with
WorkflowTransitionLimitation set to
will allow the Technical team to send content to proofreading after they are done with technical review.
You can also use the Workflow Stage Limitation together with the
content/publish Policy to limit the ability to edit content in specific stages.
For example, you can use it to only allow Technical team to edit content in the
Workflow makes use of the Symfony Workflow Component, but special Ibexa DXP treatment is covered in the Workflow service.
The service implements the following methods:
start- places a Content item in a workflow
apply- performs a transition
can- checks if a transition is possible
can are the same as in Symfony Workflow, but the implementation in Workflow Service
extends them, for example by providing messages.
You can also use the following methods to read information about workflow from the database:
loadWorkflowMetadataForContent- reads all workflow information about a Content item (as
loadWorkflowMetadataOriginatedByUser- reads all workflow actions performed by the provided user (as
loadAllWorkflowMetadata- reads all workflow information from the system
\EzSystems\EzPlatformWorkflow\Value\WorkflowMetadata object contains all information about a workflow, such as ID, name, transitions and current stage.
\EzSystems\EzPlatformWorkflow\Value\WorkflowMetadata::$workflow gives you direct access to native Symfony Workflow object.