Is there any reason why workflow states are stored against nodes rather than revisions? As reflected in the workflow_node table, this implies that a node can only ever be in one "global" state, rather than a state dictated by the current revision

This causes problems when attempting to integrate with the Revisioning module for example. I need the current revision of a node to be published (state = live), whilst an unpublished revision is being edited behind the scenes by the author (state = draft), however this does not appear to be possible.

Revisioning module on its own can achieve this functionality, but does not support states / state access etc that you get with Workflow

Is there a way around this, or does the module need to be patched?

Comments

lelizondo’s picture

Category: support » feature

I'm having the exact same issue, it is the revision that goes through the workflow, not the node. I thought I had some misconfiguration but unfortunately I see that I'm not. I hope we can find a solution soon.

RdeBoer’s picture

Agree with above posters that Workflow based on revisions rather than nodes would be ideal.
It is workable though. See also #843482: Issues integrating Revisioning with Workflow module.
Have you tried this tutorial about Revisioning in combination with Workflow ?

lelizondo’s picture

I've been reading that tutorial to setup my site, but now that you mention it, I'll double check my setup. I just probably did something wrong, combining Revisioning/Workflow/Taxonomy Access could be a little confusing.

lelizondo’s picture

After a few hours reading the tutorials and making experiments I finally configured Workflow/Revisioning/Taxonomy Access to work together. I'll definitely take some screenshots and publish them as a tutorial, it's easier than reading through confusing paragraphs.

Only one thing is not working, every time I edit a 'live' revision, a new revision is created, that's OK since that revision should go through the workflow, but I wish there could be a way to change automatically the state of the new revision to 'in draft' since right now it stays as 'live' and the workflow is not respected.

RdeBoer’s picture

@ #4
More screenshots would be great Luis!

Regarding the one thing that isn't working for you.... Wouldn't you configure your workflow permissions so that content is NOT editable in the 'live' state.. This forces authors to change the state to 'in draft' before they can edit content.

Rik

lelizondo’s picture

Category: feature » support

That could actually be a solution, but I've been working in some automatic approach, so when a node is edited, a new draft is generated.

Actually, after trying for 2 days, I think I have a solution that I'll be posting tomorrow. Unfortunately, is not exactly what I wanted but is close enough.

I had to use Rules since Actions/Triggers have no support for conditionals, so a Rule changes the state to 'draft' WHEN an existing content is edited AND the current state is 'live'.

The only problem now is when I move a node from 'in review' to "live", the node moves to "live" AND to 'draft' in the same step. So, now I have all my nodes in 'draft'. I think this is the closest I'll get, at least not without creating my own module with some hook_nodeapi.

It will all be clearer with some screenshots.

lelizondo’s picture

@RdeBoer Done. I've created a tutorial with lots of screenshots, I hope this clarifies the process since it is confusing by nature. I would like to read some thoughts.

RdeBoer’s picture

@#7
That's great! Where did you put your tutorial?

lelizondo’s picture

That's funny, I forgot to mention the most important part of what I wanted to say. http://drupal.org/node/861158

RdeBoer’s picture

#9:
Wow -- this is a substantial piece of work! Great stuff. I feel many people will find this useful.

Bastlynn’s picture

I'll take a look at this idea once I get some other things knocked down first.

johnv’s picture

This would be possible if Workflow were a 'true' Field API field, as proposed in #2019345: Create a 'Workflow Field' with Widget, Formatter, Fieldtype

johnv’s picture

Version: 6.x-1.4 » 7.x-1.x-dev
Status: Active » Closed (duplicate)

Let's focus on #2019345.

johnv’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Category: Support request » Feature request
Issue summary: View changes
Status: Closed (duplicate) » Active

There has been substantial rework on the module.
There are still some pieces missing:

  1. when using 'workflow_node', the 'current workflow state' is still per active version only (since the data is store in the version-agnostic table {workflow_node}. Probably, I consider this a won't fix.
  2. when using 'workflow field', the 'current workflow state' is stored as a field, hence version aware.
  3. the {workflow_history} does not contain a version, yet. This must be fixed by appending the table with a field 'vid'. After that, you can query for the history of a particular version.
Uccio’s picture

I tried the latest version (workflow_field) and the "Revisioning module" but the "field" is not able to know the correct state.

johnv’s picture

@Uccio, I don't know the Revisioning module. Have you tried Diff module?

Uccio’s picture

@johnv the module https://drupal.org/project/revisioning is very useful to enable the revision of the contents showing only the master revison (until you decide to approve new revision version and post that)

The versioning + workflow are the final solution to the management of complex documents with states and revisioning because with this solution you can have a published node that is reviewed by the editors and when ready, it will be made public.

johnv’s picture

"Added 'revision_id' to {workflow_node_history} when saving a transition." is now committed here.

This still doesn't help, but creates an infrastructure upon which one can build Views handlers/patches to read transitions per revision.

johnv’s picture

Issue summary: View changes
Status: Active » Fixed

I guess this is fixed.
Uccio, please open a new issue, if you're not satisfied with #15-#17.

ATM, there are no Views handlers for revisions, but patches are accepted in a newly opened issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.