Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
My requirement is that in a workflow when the state changes from one state to another,mail has to be sent.I have set a rule for this.The event as "workflow state has changed",condition as "check workflow transition" and the action as "send mail to all users of a role". But this rule is not getting triggered. Please help me out.
Comment | File | Size | Author |
---|---|---|---|
#46 | 1427006-workflow-state-transitions-46.patch | 506 bytes | rickmanelius |
#28 | workflow_transition_check_1427006.patch | 977 bytes | Aron Novak |
#18 | workflow-rules-transition-1427006-18.patch | 2.75 KB | berenddeboer |
#8 | workflow-rules-transition-1427006-8.patch | 1.22 KB | Bastlynn |
Comments
Comment #1
mwallenberg CreditAttribution: mwallenberg commentedI have also set up a rule that uses "Check workflow transition". The rule works when "Old workflow state" is set to ANY state, but if I select a specific state, then the condition is always evaluated to FALSE.
The condition is used in a component rule, which takes a node as argument. The component rule is used by a triggered rule in answer to the event "Workflow state has changed".
I am using 7.x-1.0 with rules 7.x-2.0.
Comment #2
Patribus CreditAttribution: Patribus commentedHello! Same problem here!
Any solutions to this problem?
Comment #3
markgp CreditAttribution: markgp commentedIt appears to me that
workflow_node_previous_state
is returning the currentsid
rather thanold_sid
as it should be. The following fix worked for me (apologies, I don't know how to make patch files).I should note that my rule evaluates on "After updating existing content". Not sure if that makes any difference.
Comment #4
Patribus CreditAttribution: Patribus commentedHi!
Thanks for the code. I'll edit my file and check if it works.
Pat
Comment #5
Bastlynn CreditAttribution: Bastlynn commentedPlease let me know if this worked for you. If so I'll test it on my end as well and get it into the dev branch.
Comment #6
rhayun CreditAttribution: rhayun commentedLook like #3 fix the problem..
what about release new version that fix this?
Comment #7
jramby CreditAttribution: jramby commentedHi,
Same problem here even in dev version... I didn't try this patch in 7.x-1.0.. In dev version the function seem to already have this "new line" but the same problem persists.
Comment #8
Bastlynn CreditAttribution: Bastlynn commentedTry this patch, let me know if it works.
Comment #9
chris.smith CreditAttribution: chris.smith commentedWe just upgraded to Workflow 7.x-1.0 and this issue still exists. We have Rules 7.x-2.1. The patch in #8 does not work for us.
Comment #10
Patribus CreditAttribution: Patribus commentedI used the code in #3 and it works just fine.
Comment #11
chris.smith CreditAttribution: chris.smith commentedCould you confirm what version of Workflow and Rules you are using? The most recent version of Workflow includes the changes in #3, but the problem still exists.
Comment #12
n8handler CreditAttribution: n8handler commentedI can confirm that the patch in #8 fixes the issue. I am using 7.x-1.0+18-dev, the code is not already present in this version and 18-dev is the latest version at the the of this writing. Also the patch in #8 changes more than just the line in #3 (not sure if that's relevant).
Comment #13
Patribus CreditAttribution: Patribus commentedI'm using workflow 7.x-1.0+9-dev
Comment #14
chris.smith CreditAttribution: chris.smith commentedJust validated to be working on dev-19. Thanks for your help.
Comment #15
nevets CreditAttribution: nevets commentedBug still exists in latest D7 dev release, changing $last_history->sid to $last_history->old_sid fixed the problem.
Comment #16
dmadruga CreditAttribution: dmadruga commented#3 works beautifully!
Thks, markgp! You saved my Friday :-)
Comment #17
jorgecsilva CreditAttribution: jorgecsilva commentedThank you markgp!! #3 worked for me also...
Comment #18
berenddeboer CreditAttribution: berenddeboer commentedThis is a reroll of #8 against version 1.0 for those not using the dev version.
Comment #19
jaarong CreditAttribution: jaarong commentedI take it that this patch is not in dev? Is there a chance it will make it in soon?
Comment #20
Finn Lewis CreditAttribution: Finn Lewis commentedI can confirm that the patch does NOT appear to be in the latest dev.
The dev version just downloaded (7.x-1.0+19-dev) has this on line 781 of workflow.module:
Changing this to:
and rules kick in as expected when workflow state changes from one state to another.
Comment #21
mwallenberg CreditAttribution: mwallenberg commentedI can just confirm that the change described in #3 works for my setup (I am using 7.x-1.0 with rules 7.x-2.0.)
Comment #22
cswan CreditAttribution: cswan commented#3 worked for me also. Thank you! ... I'm using Workflow 7.x-1.0 with Rules 7.x-2.2.
Comment #23
pumpkinkid CreditAttribution: pumpkinkid commentedI too was able to correct this thanks to #3... however, I had updated to the Dev version and as described in #20, noticed the line in question is different...
Looks like the line in dev should read:
Anyone think that first "!$last_history" also needs to be changed?
Comment #24
shenzhuxi CreditAttribution: shenzhuxi commented#18 works for 1.0
Comment #25
shenzhuxi CreditAttribution: shenzhuxi commented#8 works.
#18 can't be used with drush.
Comment #26
Sebastien VR CreditAttribution: Sebastien VR commented#20 works for dev-version (v +20)
Comment #27
nubeli CreditAttribution: nubeli commentedPatch in #8 works for me with dev version +20.
Comment #28
Aron NovakAnother attempt, for 1.0
Comment #29
nagy.balint CreditAttribution: nagy.balint commented#28 works perfectly for 1.0
Before this the rule always got fired on each node update, even if the status didnt change. But now it works fine with this patch.
Comment #30
shenzhuxi CreditAttribution: shenzhuxi commented#28 works with Drush 5.8
Comment #31
NancyDruWhich version should we commit?
Comment #32
NancyDruWith at least two different patches following the RTBC, we need it reviewed again.
Comment #33
haggan CreditAttribution: haggan commented#28 Patch did not solve the rules problem on dev version 25
/Jonas
Comment #34
nagy.balint CreditAttribution: nagy.balint commented#28 Patch has to be modified to work on the latest dev. It was originally made for 1.0 and there are some code changes.
Comment #35
NancyDruLooks like BastLynn's patch in #8 is the winner!
Comment #36
nagy.balint CreditAttribution: nagy.balint commentedI think that with #8 if you set the rule up to react on node update, and to have the transition condition, then that rule will always fire (meaning even if you dont change the status it will always fire).
Comment #37
NancyDruWell, please test it after I commit.
Comment #38
NancyDruCommitted to -dev.
Comment #39
darko.ljubic CreditAttribution: darko.ljubic commented7.x-1.0+35-dev
"Check workflow transition" still not working (for me)!
The event is "workflow state has changed".
Comment #40
NancyDruI don't see where you're getting "Check workflow transition." The correct rule should be "Workflow state has changed."
Comment #41
darko.ljubic CreditAttribution: darko.ljubic commentedWhat I meant was that the rule is not doing what it is supposed to do when I set EVENT to "workflow state has changed", CONDITION to "check workflow transition" and action to whatever .
I tested the code and found out that the problem is caused by workflow history fetching method...
In dev release
workflow_get_recent_node_history
was used, and for that particular function the return value is being cached (statically inside the function), and by the time we call it, it has "stale" workflow history data because workflow state has indeed changed (our EVENT occurred). So$last_history->old_sid
contains the old state id from previous state change, not the last one.I highly recommend that we use
workflow_get_workflow_node_history_by_nid
function that is NOT CACHING the return value of last workflow history state. This function was used in recommended release (7.x-1.0).I tested it, and it works. Can you please confirm?
I'm sorry, I don't know how to make patch files. I promise I will learn it as soon as possible :)
Comment #42
berenddeboer CreditAttribution: berenddeboer commentedMaking a patch is very simple if you got installed the dev version by cloning with git. Then you just say "git diff".
Comment #43
NancyDruYes, it would be, if that's the right patch. Removing the caching might be better.
Comment #44
NancyDruIncluded in 7.x-1.1-beta2.
Comment #45
rickmanelius CreditAttribution: rickmanelius commentedI'm re-opening this thread because the latest beta (7.x-1.1-beta3) needs the adjustments in #41 to work properly. Previously, the patches noted in #44 fixed the situation where a new node was being created, but it was not working for "Workflow state has changed" event. I have a client with a very involved set of rules with several state transitions that I test with Selenium, and adding #41 brought me back to a green board.
Comment #46
rickmanelius CreditAttribution: rickmanelius commentedAnd here's a patch...
Comment #47
NancyDruI removed the static caching. Hopefully the database will have it cached if it is needed again.
Comment #48
shenzhuxi CreditAttribution: shenzhuxi commentedThe lastest dev still needs patch #46 to work.
Comment #49
NancyDruThen the description in #41 is wrong?
Comment #50
rickmanelius CreditAttribution: rickmanelius commentedI'm wondering if the downloadable version was not already in place at the time of #48.