There is a need to re-architect parts of Workbench Moderation to handle many issues we see in the issue queue and to help the module more easily manage its data. In addition, this re-architecture can build a framework that would allow for new feature requests we are seeing (and also wanting!) that can not be easily implemented with the current architecture (e.g. multiple approvals before publishing and multiple moderation workflows e.g. having a different set of states and process for one content type vs. another).

This ticket is a place to cross reference related issues.

Comments

alberto56’s picture

alberto56 commented

Related issue: #1314508: Make states/transitions exportable with the Features module

thanks,

Albert.

stevector’s picture

stevector
he/him
commented
Assigned: robeano » Unassigned

Robeano and I had a conference call last week with the maintainers of State Machine. We talked about how many of the architectural goals of Workbench Moderation could be achieved more easily using a solid API foundation like the one in state machine/state flow.

I'm opening a 7.x-2.x-1316314-unstable branch to experiment with a version Workbench Moderation that extends the State Flow class.

stevector’s picture

stevector
he/him
commented
Version: 7.x-1.x-dev » 7.x-2.x-dev

I've made a 2.x branch. It is currently identical to 1.x. Having it as a separate branch allows for better organization of these d.o issues.

rerooting’s picture

rerooting commented

Proper link > http://drupal.org/project/state_machine

rerooting’s picture

rerooting commented

-- removed an ill-placed question about the future of state machine & workbench 2.x modules --

douggreen’s picture

douggreen commented

I am having problems with workbench_moderation, entity_translation, and title modules working together. What is the state of the 2.x version, which is now 1.5 years old? Should I use it and should I make patches for translation (if there turn out to be any) to the 2.x version? Or should I stay on the 1.x version and try fixing it?