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
Comment #1
lelizondo CreditAttribution: lelizondo commentedI'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.
Comment #2
RdeBoerAgree 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 ?
Comment #3
lelizondo CreditAttribution: lelizondo commentedI'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.
Comment #4
lelizondo CreditAttribution: lelizondo commentedAfter 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.
Comment #5
RdeBoer@ #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
Comment #6
lelizondo CreditAttribution: lelizondo commentedThat 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.
Comment #7
lelizondo CreditAttribution: lelizondo commented@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.
Comment #8
RdeBoer@#7
That's great! Where did you put your tutorial?
Comment #9
lelizondo CreditAttribution: lelizondo commentedThat's funny, I forgot to mention the most important part of what I wanted to say. http://drupal.org/node/861158
Comment #10
RdeBoer#9:
Wow -- this is a substantial piece of work! Great stuff. I feel many people will find this useful.
Comment #11
Bastlynn CreditAttribution: Bastlynn commentedI'll take a look at this idea once I get some other things knocked down first.
Comment #12
johnvThis would be possible if Workflow were a 'true' Field API field, as proposed in #2019345: Create a 'Workflow Field' with Widget, Formatter, Fieldtype
Comment #13
johnvLet's focus on #2019345.
Comment #14
johnvThere has been substantial rework on the module.
There are still some pieces missing:
Comment #15
Uccio CreditAttribution: Uccio commentedI tried the latest version (workflow_field) and the "Revisioning module" but the "field" is not able to know the correct state.
Comment #16
johnv@Uccio, I don't know the Revisioning module. Have you tried Diff module?
Comment #17
Uccio CreditAttribution: Uccio commented@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.
Comment #18
johnv"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.
Comment #19
johnvI 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.