Default configuration definitions
Default configuration example with an installation with editorial OC and public OC
Last updated
Default configuration example with an installation with editorial OC and public OC
Last updated
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- 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”
This means that the IPTC-names represent the standardized definition, whereas the the other are customizations.
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:
Example of transistion in code:
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. With the priority specified you get the “Publish changes” button in increased sized and on top.
In code this is written:
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)
An example of actions in the configuration code:
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.