Default configuration definitions
Default configuration example with an installation with editorial OC and public OC
Definitions
What is Workflow States?
The status of the article is described by "pubStatus". Each workflow normally is given a name that represent the state. The workflow itself describe the Pubstatus and to what state or other states (nextStates) the article can transition to. The transition can be controlled by certain preconditions that may be present.
To understand that the Workflow has a name that corresponds to a pubStatus is an important step on the way of understanding the configuration. The publish flow can be configured with any pubStatus. Here are some common workflow states in the publish flow.
If the status reflect an IPTC- name standard it has a name as “stat:xxx” and if it is a customized status it is has a name of “imext:xxx”.
DRAFT is "imext:draft"
APPROVAL is "imext:done"
SCHEDULE is "stat:withhold"
PUBLISH is “stat:usable”
REPUBLISH is “stat:usable”
PUBLISHCHANGES is “stat:usable”
UNPUBLISH is “stat:canceled”
Transitions - the path to nextState
This is what or which states that the article can transition to. It is described with “nextState” in the configuration. The transitions are controlled with preconditions. See the figure from above again:
Priority - useful if you need a priority button
A transition state; i.e. nextState can be given a more visible primary or secondary button in the dialog by specification of priority in the configuration. See the Publish now button that is now placed higher up in the dialog compared to a configuration without priority specified.
Actions
Can be described as what will happen when the workflow state is entered. The actions are optional to add to the configuration. The following are available:
pubStart
pubStop
pubStatus
hasPublishedVersion (see below)
Published to public repository - Defining the flag hasPublishedVersion
In the configuration you use the flag hasPublishedVersion to sign that the article is in a state with a published version.
To use this function the content must be stored in two separate Open Content repositories. One that stores the editorial version/versions and one that has the article version/versions that is published, i.e. editorial Open Content and public Open Content. This is fundamental for the installation and the publish flow and not an effect by the publish flow configuration, instead the environment must have these fundamental installation units to be able to be configured with the hasPublishedVersion-flag.
The article is either published or unpublished and that is set as an action in the configuration with the hasPublishedVersion flag as either true or false. This flag is then used as a precondition for other transitions to happen.
Last updated
