#52: Placeful workflow support for Plone

Contents
  1. Motivation
  2. Proposal
  3. Implementation
by Maik Röder last modified Jan 21, 2010 07:29 AM

Our goal is to be able to say that in a given folder, a different workflow (or workflow chain) should be used for certain content types.

Proposed by
Maik Röder
Seconded by
Encolpe Degoute
Proposal type
Architecture
Assigned to release
State
completed

Motivation

Use case 1: Workspace workflows

We want to have a different workflow for Documents in Workspaces.

The workflows for documents can be radically different in Workspaces.
For example you may want to define special permissions for local roles
like "GroupMember" and "GroupAdmin", which are not applicable and make
no sense in the standard workflows.

We don't want to change the standard Plone workflows to fit the
needs of the optional WorkSpace product.
We don't want to manage our Permissions in the workflow states of
the standard workflows.
We can't add or remove workflow states in the standard workflows.
We can't add or remove workflow transitions in the standard workflows.
We don't want to derive from the standard content types just to
define a different workflow to our new content type.
We want the standard workflows to remain intact and be upgradable when
new versions of Plone arrive.
We don't want to mess with the aquisition settings in certain workflow
states just to reach our special goals with the Workspaces.

We want to deliver our implementation of WorkSpaces (GrufSpaces) with
a set of clean workflows which are installed next to the standard workflows,
and can be applied to any content type inside of the WorkSpaces.

Use case 2: Publish only

To keep things as simple as possible, all News Items added in a
certain folder should be published and remain in the published
state until they are destroyed or moved away.

We don't want to have some documents in a private/visible/submitted
state hidden in this folder.

To achieve this goal, we add a workflow with only the state "published".
The Folder is marked with our special policy.

Use case 3: Force external publish

Let's say we want members to be able to add content to their
Member folder, but we want them to submit their documents somewhere
in the hierarchy of the public site, not inside of their Member folders.
To achieve this goal, we want to be able to say that all
Member Areas have a different workflow chain associated, which enforces
submission to the public site.

Proposal

Our goal is to be able to say that in a given folder, a different workflow (or workflow chain) should be used for certain content types.

The mapping of content type to workflow chain can be managed in the workflow tool, but there is no way to associate a document dynamically to a workflow chain in a given folder.

For inspiration, we studied an implementation example of a placeful workflow for the CMF found in the Collaborative Portal Server.

Implementation

Advanced Workflow

In the latest Plone version (2.0.4), the workflow configuration configlet is not yet made available to the portal manager, but exists already as an unfinished template. The following is a mockup showing the Advanced Workflow configlet as it could look like.

Workflow policy mapping

In the Plone workflow configuration, you will also be able to access a section that allows a portal manager to change the predefined Workflow policy mappings. The following interface shows the example of three different policies. Adding new policied is also possible from this interface. To edit one of the policies, the portal manager has to click on the title.

Workflow policy mapping

We need a workflow policy id to be able to make a reference from a folder to the policy. The title is needed to be able to show a clear name to the portal manager in the Workflow policy mapping interface. The description of the Workflow policy is necessary for documentation purposes. The main part of the interface looks exactly like in the Advanced Workflow interface.

Selecting a Workflow policy mapping in a Folder

After having configured the Workflow policies, the portal manager can define workflow policies in a normal folder, using the content menu drop down of Plone, which we extend with a link called "workflow":
Clicking on the Workflow link leads to a page where the portal manager can select which policy is going to be used for the folder and/or for content added below this folder.

Placeful workflow tool

The placeful workflow tool contains the definitions of all workflow policies. The chain_by_type property of the WorkflowPolicyDefinition class is a PersistentMapping just like the one used in the Workflow tool. The max_chain_length property is used to define the workflow chain length. This is set to 1 by default, as most Plone sites will only have one workflow assigned to a type. This assumption leads to a simple placeful workflow configlet. We will later show how to extend this simple interface for max_chain_length > 1.

Placeful workflow configuration

Placeful workflow definitions are stored in a dot file called ".wf_policy_conf". The "workflow_policy" property defines the policy for content added to the folder itself, and the "workflow_policy_under" defines the policy for everything below the current folder. The two policies for "in" and "below" the folder are necessary because it is possible that there are different workflows that apply in the two cases. If we only had the option to let policies apply to the whole folder, then we could never make the difference for the folder itself.

Changes to the workflow tool

The only place in the workflow tool where we have to change something is in the getChainFor method. This method gets the default mapping of type to workflow chains. We just need to add a few lines of code to this method that will ask the portal_placeless_tool to look for a placeful configuration, and if it exists will update the mapping of content types to workflows before proceeding.