Rules integration for Workflow
NickSI - February 6, 2009 - 10:28
| Project: | Workflow |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
| Issue tags: | gsoc:rulesmonkey, rules integration |
Description
As current version of workflow lacks integration with Rules, so I've ported integration module from D5. Just unzip the archive into your workflow module folder (or, actually any module folder) and enable module.
| Attachment | Size |
|---|---|
| contrib.zip | 2.5 KB |
#1
Subscribe.
Will hopefully get a chance to test sometime soon
#2
Thanks. This is great!
#3
Same as #257833: When saving a node, the workflow ng transition rule is triggered, even though workflow has not changed
I think that checking tokens in Rules is ugly.
What about 2 Rules events:
This needs some more thought, so setting it to "needs work"
#4
Here is updated module. Changes from original port posted in this issue:
No more comparing tokens to find out!
It is invoked when workflow is updated with comment, but no state change happened.
Note 1: in case workflow state has changed and comment was added at the same time only "Workflow state has been changed" rule will be invoked, not both.
Note 2: currently it is commented in module code, because for proper work it requires patch #472966: Implement subsequent runs control. (see comments in module code).
#5
I will work on the Rules integration during my Google Summer of Code project.
* I will recycle your code and extend it
* I will provide valid patches against the Workflow CVS dev branch
* I think we do not need a separate module. I will let the code live in a workflow.rules.inc file
#6
Great news.
Too bad your patches won't be commited cause workflow seems to be unmaintained. So if you intend to make it part of Workflow, obtain commit access also, hehe...
#7
Here is a first patch. Currently there is only one event that occurs if a transition to a different state has been made. A condition is also included to check the transition states.
TODO:
* Add event for non-state-changing transitions with comments
What other events, conditions and actions would you like?
#8
New patch:
* Added event for workflow comments only (also added
unset($node->workflow_comment);to avoid double execution of a state transition, inspired by #472966: Implement subsequent runs control.).* Also added
$node->workflow = $sid;after the transition to avoid the double execution.#9
I think you should not put fix from #472966: Implement subsequent runs control. inside this patch, because duplicate runs is different problem, not just local to Rules integration and that patch in #472966: Implement subsequent runs control. also should fix subsequent duplicate runs for other modules.
Stating that Workflow integration requires that patch would be enough.
#10
OK, I added a patch suggestion in #472966: Implement subsequent runs control..
This patch here depends on my patch there, so apply the other patch first.
#11
New patch to fit for #472966: Implement subsequent runs control..
#12
I applied the patch from http://drupal.org/node/472966#comment-1906724 and give this a test. I tried both events, the condition and also using the core action with rules - works as it should :) Also code style is looking fine, so I set this to RTBC.
Having this integration would help the user that want to use workflow with rules (see #396086: Help using Workflow's states with Rules) a lot, till know users relied upon tokens to detect workflow transitions. Having the separate condition of this patch is much better.
#13
track
Edit: After all i use trigger (integrated in D6 core & with workflow) to fire rule sets.
#14
Tracking
#15
I try patch #11 with #9 on #472966: Implement subsequent runs control. .
All seem to work fine thanks
2 feature requests:
- access to the "unchanged content" on the event "workflow state has change".
- on the event "content is going to be saved" a condition to check the value of the new workflow sate.
Edit: perhaps this bug can help #327144: workflow-state tokens are reversed
#16
Great patch;
For the lazy minded that don't want to add ORs for each potential state, the which state could be a multi select under "check workflow state"
Attached patch changes that, haven't tested heavily. (assumed patch 11 applied, ie doesn't include 11).
#17
I've had some issue with this, same as in #445084: Adjust module weight from 0 however adjusting weight did not help. The triggered rule was returning the $node in the array('node'=>$node) format to resave in a 'custom php' do action. (The rule was set up to set published, changed date to now when workflow state changed to my 'published' state).
#18
(Nevermind, probably the subsquent patch will fix it).
#19
I've had an ugly issue with this patch: http://drupal.org/node/616664
Indeed it was only with the single selectable implementation from klausi nr 11... where too strict checks led to this issue.
Rules integration checked for === between numbers as string and numbers as int - whereas they where treated unidentical
Switching to the multiple selectable version containing checks with in_array led to a perfect working solution.
I'm going to submit a new patch containing checked workflow.module rules integration with multiple support (11 and 16) with tiny formatting corrections. This patch should really be production ready and candidate for CVS now.
Rerolled against current -dev of today, with need to change one hunk.
#20
making it unassigned.