Multi-workflow support for Plone

Development Developing for Plone
, ,
1

Some content has more than one lifecycle at a time. A person's profile is published or private, and — quite separately — their Foundation membership is pending, active or lapsed. An organization is published, and separately it is listed or verified.

Plone has one answer for that today: review_state. So we fold both lifecycles into one workflow and multiply its states, split the content into two types, or drop the second lifecycle into a plain field and give up guards, transition permissions, history and role mappings.

The odd part is that the machinery for doing better has been in CMF all along. portal_workflow supports a chain of workflows, getChainFor resolves it through a multi-adapter, and DCWorkflow keys status records by workflow id. What is missing is everything around it — the catalog, plone.api, plone.restapi, the history viewlet, Volto — all of which read review_state and stop there.

I wrote up the whole story here:

:link: Published and pending: multi-workflow support for Plone

The add-on

collective.multiworkflow makes a chain usable across the stack, driven by behaviors rather than by editing portal_workflow type by type:

<plone:additionalworkflows
    marker=".behaviors.IMembership"
    workflows="membership_workflow"
    label="Membership"
    />

Contributed workflows are appended, never substituted, so review_state keeps meaning what it means today and content without the behavior is served exactly what Plone has always served. One catalog index covers the whole chain, @workflow gains a chain key, and the companion Volto add-on renders a selector per workflow.

It is 1.0.0a2, so alpha, and collective.casestudy is the worked example to read. Details and install instructions are in the documentation.

The PLIP

An add-on is the wrong long-term home for this — it only works by overriding plone.restapi services, shadowing Volto components and monkey-patching plone.exportimport, all of which disappears if the change lands in core.

So the design is also filed as a PLIP, targeting Plone 6.3:

PLIP: Additional workflows contributed by behaviors

It is still [WIP], it still needs a seconder, and the issue carries a list of open questions I would genuinely like opinions on. If you have ever wanted two workflows on one content item — or you think this is the wrong shape entirely — that issue is the place to say so.

1 Like