To specify a workflow state, use the following syntax:
[stateName] label = "stateLabel" transitions.targetStateName.label = "transitionLabel" transitions.targetStateName.conditions = "conditionClass" transitions.targetStateName.conditions.conditionId.condition = "conditionClass" transitions.targetStateName.conditions.conditionId.conditionOption = "optionValue" transitions.targetStateName.conditions.conditionClass.conditionOption = "optionValue" transitions.targetStateName.actions = "actionClass" transitions.targetStateName.actions.actionId.action = "actionClass" transitions.targetStateName.actions.actionId.actionOption = "optionValue" ...
The stateName is required. Each state can specify zero or more transitions with zero or more conditions, and zero or more actions.
For example, the following is a specification of an example workflow:
[draft] label = "Draft" transitions.review.label = "Promote to Review" transitions.review.actions.email.action = "SendEmail" transitions.review.actions.email.toRole = "reviewers" transitions.published.label = "Publish" [review] label = "Review" transitions.draft.label = "Demote to Draft" transitions.published.label = "Publish" transitions.published.conditions = "False" [published] label = "Published" transitions.review.label = "Demote to Review" transitions.draft.label = "Demote to Draft"
|Dead End States|
If a state has no defined transitions, then it is considered to be a dead end. If a content entry enters this workflow state, it is not possible to transition it to another state until the workflow is modified to include a valid transition. This could affect your ability to publish content, or take published content through your workflow for further editing.
|Condition and Action Class Short Names|
Conditions and actions are typically expressed by their short name, such as False or SendEmail respectively. This may lead to a name conflict if multiple modules provide conditions with the same short name. In this case, the most recently loaded module's definition (which can vary) is used during workflow processing.
You can use the following condition classes to control transitions:
Table 5.1. Conditions
|Condition Class||Description, Example, Options|
Checks whether the content entry contains the specified text in at least
one element. The available options are:
The following example specifies that the string "example" must be exist in the title or body elements:
transitions.example.conditions.Contains.fields = "title" transitions.example.conditions.Contains.fields = "body" transitions.example.conditions.Contains.string = "example"
A condition that always returns false. This is useful if you need to
disable a transition for a period of time. Simple remove the condition
or replace it with another condition that can succeed to re-enable
transitions.example.conditions = "False"
Any condition may be negated by providing the negate option. For example:
transitions.example.conditions.Contains.string = "dangerous" transitions.example.conditions.Contains.negate = true
You can use the following action classes to invoke during transitions:
Table 5.2. Actions
|Action Class||Description, Example, Options|
Sends an email message regarding the transition. The available options
The following example would cause an email message having the subject "Subject" and beginning with "Check it out." followed by the body rendered from the template
transitions.example.actions.SendEmail.to = "administrator" transitions.example.actions.SendEmail.to = "editor, email@example.com" transitions.example.actions.SendEmail.toRole = "reviewers" transitions.example.actions.SendEmail.toRole = "editors, members" transitions.example.actions.SendEmail.subject = "Subject" transitions.example.actions.SendEmail.template = "custom-email-template.phtml" transitions.example.actions.SendEmail.message = "Check it out."