Last week I was working on the State Machine integration.

#1316314: Workflow Architecture for Workbench Moderation

And was looking at the concepts of "events." In Workbench Moderation 1.x we have states like "Draft," "Needs Review," "Published," and the ability to define new states. Users can move nodes through these states using "transitions." A transition is just a directional relationship between two states. So Draft-to-Needs-Review is transition and Draft-to-Published is another. Each transition has a corresponding permission. So a site builder can give the Draft-to-Needs-Review permission to a wide set of roles and Draft-to-Published to administrators only. Adding just a few more states can quickly explode the number of transitions.

State Machine uses the concept of events instead of transitions. In an event, a target state is defined along with allowed origin states. So site builders can make the switch to "Published" the same for the "Draft" and "Needs Review" origin states. Or the site builder can make them separate events.

I may have gotten ahead of myself in that at present, the only way for a site builder to do this with State Machine is by writing more code. And that is what I started to address in this unstable and far-from-finished branch

http://drupalcode.org/project/workbench_moderation.git/shortlog/refs/hea...

I've know for a few months that I wanted to use CTools Access plugins to define whether a user may move to the next state. So I looked at other modules that use them and the simplest one I found was Ctools Access Ruleset. This is a module that allows for the building up of complex access plugins from existing access plugins. CTools Export UI makes this seemingly complex task surprisingly light. So in the branch linked above I've added a workbench_events submodule that started as a copy and find-and-replace of ctools_access_ruleset and I didn't have to do much get it defining "events" and hooked up to a class extending StateFlow.

For now I'm looking for feedback on whether Export UI is the right tool for defining events. I've also got a start on using it to define "workflows" though that is even less fleshed-out.

So should Export UI be used for states/events/workflows? If the answer to that question is yes, then we can figure out where these should go. State Machine, Workbench Moderation, Workflow? Should states, events, workflows be separate modules within one of those projects (Right now Workbench_events and workbench_Moderation have cross-dependencies). Do states, events, workflows, also need to each be their own plugin types in CTools the way "Content Type" and "Access" are in order to most effectively pass contexts among each other?

Comments

stevector’s picture

The most stable version of this currently is in the branch 7.x-2.x-unstable-ers-state-machine which is explained here #1398994: Attempt to Merge with ERS and State Machine

stevector’s picture

Status: Needs review » Closed (duplicate)

I have moved this work to a sandbox: http://drupal.org/node/1294880

stevector’s picture

Wrong URL in #2. This is the sandbox: http://drupal.org/sandbox/stevector/1405838

murz’s picture

Can you describe more what we must select in this page?
admin/config/workflow/workbench-workflows/workflows/list/default_workflow/edit/context
- I see long list of fields that have links and not understand what I must select...
And which version is active now - from your sandbox of from official workbench_workflows repository?

Mark F’s picture

The old transition matrix is a miss. It was complex and ugly although it was obvious what you needed to do. I speak from the standpoint of someone needing an onramp at this point.