Plone Workflows – Part 1
The first part of this workshop is intended as an introduction to the topic Plone workflows alltogether. It will attempt to convey how the Plone workflow concept is structured and what concepts are associated with it. The next part of the workshop will go into detail as regards the application of workflows. The main goal of this introduction is merely to explain the Plone workflow concept and the terminology adherent to it.
Introduction
We will be using the term workflow as a general job process. Processes within a company, for example, are often referred to as workflows. This can include certain processing regulations within a specific department. We will however solely have to do with the Plone workflow concept. These assist in defining the status of the article types. Through them it is possible to define, at any point in time, in what state an article is and through what triggering mechanism it will proceed to the next state. A workflow is basically composed of states and progressions.
The change from one state into the next always takes place via a progression. Under Plone, a workflow is always connected to an article type. This asertains what state the article is in and how to proceed to the next state. The progressions are closely knit to the Plone user role. This means that certain progressions can only be triggered by certain users with respective roles. How this is exactly accomplished will be outlined in detail in the next workshop part. The user concept of Plone purveys the following roles:
This is provided for visitors who are visiting the page but not registered on the system.
Authenticated
Every user who has access to register on the system automatically possesses this role.
Member (Author)
This role is automatically appointed at the time of generating a new access. Memebers have limited rights but can already contribute content.
Reviewer (Editor)
Users with this role can publish content. This means content provided by other memers (authors) for review and publishing.
Manager (Administrators)
This role inclues all rights provided Diese Rolle beinhaltet sämtliche Rechte in Plone.
Owner
This role provides a user with the right to edit all articles. Every member becomes an owner of one's own articles automatically.
Plone provides two standard workflows. For one, the Plone workflow, intended for content type and the folder worflow for the directory types. These worflows dispose of a multitude of states and progressions. The following image shows the states and progressions of the individual standard workflows in Plone.
The image above shows the standard plone workflow for the content types. The starting state in defined as public draft (visible). Each article connected to this workflow automatically ends up in this state after having been generated. When authors create articles underlying this workflow, they are by default visible, i.e. they can be read by all users. The author can privatize the article via hide - in such an instance only users with the relevant role can read the articles. The article then changes into the private state. Via show the article can be made visible again. If an author wants to forward an article to an editor this takes place via publish, which in turn decrees the article a state of pending. The editor can then refuse the article by triggering the progression reject. The author can also cancel his article forwarding using retract. Via publish, both the author and the editor, have the possibility to publish articles, i.e. to make them visible to all.
The following image depcits the workflow process for folder types in Plone.
Progressions
Member makes content private (hide)
This progression changes an article to private - it can only be viewed by the owner or by users with manager rights, respectively by users with explicit owner rights. The article is thus moved into the private state.
Reviewer publishes content (publish)
Publish literally publishes content. The content can therefrom be viewed by all. The target state of this progression is published.
Reviewer rejects submission (reject)
Using reject an editor can refuse an article. The target state is, once again, visible.
Member retracts submission (retract)
Using retract an author can call back an article for further processing. The target state is, once again, visible.
Member makes content visible (show)
This progression can return a privatized article to a visible state.
Member requests publishing (submit)
The progression submit allows an author to forward articles for publishing. The taret state is therefrom marked as pending. Articles in this state can be posted by editors using publish.
States
Pending
When an article is forwarded by an author it is set into this state. The article can be made public by an editor, i.e. it can be moved into a published state.
Private
When an article is moved into this state it can still be read by the owner or by users with the explicit owner role. Through the progression show this process can be reversed.
Published
Published articles can be viewed by every user. A published article can be returned by an editor via reject or called back by an author via retract.
Public Draft (visible)
Articles in this state can also be viewed by all users. This state is the default standard Plone workflow state.
You can find the particulars to the status of an article, as well as the progressions, under the Portal Tabs, as shown in the image below.
Synopsis
Last, but not least, we should summarize the most important content. The basic components for workflows are states and progressions. Each article is, at all times, in one state. The change from one state into the next takes place via progressions. States and progressions are tightly knit to the Plone user concept. Progressions can be connected with certain roles. Up to now we have described the main components of a Plone workflow. In the next article, Plone Workflows - Part 2, we will demonstrate through a concise example, how to generate a workflow on the ZMI level and how to connect said workflow with an article type.