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.

Schematic Workflow State

To understand that the Workflow has a name that corresponds to a pubStatus is an important step on the way of understanding the configuration.

Prefixes of pubStatus (imext, stat and custom)

There can be three types of pubStatus-definitions; imext:, stat: and any custom-made prefix in the configuration of the publish flow.

The statuses that are prefixed with imext are historically created by Infomaker (imext:draft, imext:approved and imext:done). The stat prefix comes from the IPTC standard. See the info and examples below. The publish flow can be configured with any pubStatus and then it is a good practice to select another custom prefix that could be recognized by the organization. It is not good practice to add further custom made pubStatuses with imext-prefixes. Here are some common workflow states in the publish flow dialog.

Examples above from the publish flow dialog and what configuration pubStatus has in each status.

If the status reflect an IPTC- standard it has a name as “stat:xxx” and if it is a infomaker-made status it is has a name of “imext:xxx”.

DRAFT is "imext:draft"

APPROVAL is "imext:done"

APPROVED is "imext:approved"

SCHEDULE is "stat:withheld"

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 other are customizations.

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:

Example of transistion in code:

"transitions": [
    {
        "nextState": "publishchanges",
        "title": "Publish changes",
        "preCondition": {
            "hasPublishedVersion": true
        }
    },
    {
        "nextState": "republish",
        "title": "Republish article",
        "preCondition": {
            "hasPublishedVersion": true
        }
    },
    {
        "nextState": "cancel",
        "title": "Unpublish",
        "preCondition": {
            "hasPublishedVersion": true
        }
    },
    {
        "nextState": "done",
        "title": "Ready for approval"
    },
    {
        "nextState": "publish",
        "title": "Publish Now",
        "preCondition": {
            "hasPublishedVersion": false
        }
    },
    {
        "nextState": "withheld",
        "title": "Scheduled publication",
        "preCondition": {
            "hasPublishedVersion": false
        }
    }
]

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. With the priority specified you get the “Publish changes” button in increased sized and on top.

In code this is written:

"priority" : "primary"

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)

An example of actions in the configuration code:

"actions": [
    {
        "pubStatus": "imext:done"
    }
],

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.