Workflow API

Defines the content editorial workflows.
It includes all the logic to allow content to transition from one state to another.

Status definitions

Statuses are defined by constants in modules by adding an Enum that extends Plugins/Workflows/Statuses/BaseStatuses under Modules/[Your-Module]/Plugins/Workflows/Statuses. These should remain in the codebase, so they can be referenced programmatically, as there may be associated logic with certain states such as events, notifications etc...

Transition definitions

Transitions are also defined in the codebase since they rely on statuses.
This is done in modules by adding an Enum that extends Plugins/Workflows/Transitions/BaseTransitions under Modules/[Your-Module]/Plugins/Workflows/Transitions.

Workflow storage.

For now, workflows are defined in config under a node workflows in config/workflow_api. Eventually, workflows should be defined and assigned to content from the dashboard, stored in the database (future work).

Each workflow config is defined by:

  • label for humans
  • statuses that lists all the statuses used by the workflow
  • transitions that lists all the transitions used by the workflow
  • statusesNextTransitions that optionally provides a preferred order of transitions options for each status.

Workflow assignment to models and content.

For now, workflow assignment is done in config under the nodes model_workflows and content_bundle_workflows in config/workflow_api. Every module can extend it to assign content to a workflow. New model classes can be added to model_workflows. By default, the Content model is assigned the default workflow. Content bundle machine names can be added to content_bundle_workflows to assign a specific workflow.

Principles and module architecture.

  1. We use constants everywhere to refer to statuses and transitions.
  2. Workflows, statuses and transitions are listed by a WorkflowRepositoryInterface that should be accessed via services.
  3. WorkflowService is the main service to deal with workflows and access lists.
  4. ContentWorkflowService contains all logic to link content to a workflow.
  5. WorkflowDefinitionService feeds definition information to the repository.

Permissions

Permissions for workflows are controlled via checks on ability to perform a transition, considered a permission action.
e.g content.send_for_approval.public_notice allows users to send a public notice for approval.
Moderation options are filtered based on editor's abilities and validation rules check the selected status against the same alowed transitions.
Permissions for each transition are dynamically populated by the PopulateWorkflowPermissions listener during the permission list build, that checks for any workflow assigned to content being processed.