The latest update to Workflow has caused this error to appear while Rules tried to intervene in a state change:
Fatal error: Call to undefined method stdClass::value() in /home/user/public_html/sites/all/modules/workflow/workflow_rules/workflow_rules.rules-callback.inc on line 111
I double checked the rule's validation to see if any configuration changes were needed and rules says the rule is still valid.
An exported version of this rule that is experiencing this problem is as follows
{ "rules_set_vua_draft_from_issued_state" : {
"LABEL" : "Set VUA Draft from Issued State",
"PLUGIN" : "reaction rule",
"OWNER" : "rules",
"REQUIRES" : [ "workflow_rules" ],
"ON" : { "workflow_state_changed" : [] },
"IF" : [
{ "workflow_check_transition" : {
"node" : [ "node" ],
"old_state" : { "value" : { "5" : "5" } },
"new_state" : { "value" : { "6" : "6" } }
}
}
],
"DO" : [
{ "workflow_rules_set_state" : {
"node" : [ "node" ],
"workflow_state" : { "value" : { "4" : "4" } },
"workflow_comment" : "A new version of the Venue Usage Agreement is in the process of being drafted because of a recent change request or an error was found in the current version."
}
}
]
}
}
As a result of this my immediate solution was to revert to 7.x-2.3.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | workflow-fix-wrong-method-used-by-rule-2304365-9.patch | 694 bytes | mgadrat |
Comments
Comment #1
rbrownellI can also confirm that this is an issue in 7.x-2.3-beta3
Comment #2
rbrownellUpdated title to be more specific.
Comment #3
rbrownellComment #4
johnvAre you using Workflow Node?
Comment #5
rbrownelljohnv: Yes
Comment #6
bharathkumarkn commentedSubscribing
Comment #7
doxigo commentedI managed to reproduce this issue with a slightly different rule, this only happens in 7.x-2.4 when there's a permission issue, for instance if you set a rule to change the state of workflow but the system doesn't have the proper permission to do such transition, we end up with this error,
but in case of 7.x-2.3 version, the module returns a Error Message saying that the transition is not possible, which is the right thing to happen.
I assume it's a small bug regarding how to produce the Error message in 7.x-2.4 version.
Comment #8
derekw commentedNot a permission issue... the code comments specifically say the action is for forcing a transition.
The reason the ->value() and ->type() functions aren't working is that the node isn't wrapped.
Since it appears the code is set up for a wrapped entity and not a node, I changed:
workflow_rules.node.inc
to
workflow_rules.node.inc
Then flushed the cache, edited my Set Workflow State action (which now asks for Entity vs Content), and it all works.
Comment #9
mgadrat commentedWell that seems to do the trick... patch?
Comment #10
johnv#8 is not the answer, since it will break allcurrent implementations in the wild. ( that will be a lot since this is for WorkflowNode).
I am planning to wrap the node explicitely in an entitywrapper. Would that do the trick?
Comment #11
mgadrat commentedYeah I guess this is a good idea.
Would you use something like: entity_metadata_wrapper() in the _workflow_rules_set_state function?
Comment #12
johnvYes. Dou you have a patch ready? :-)
Comment #13
mgadrat commentedHaha no but I could look into that later today ;)
Comment #14
mgadrat commentedSorry, can't do today, It'll go to next week...
Comment #15
doxigo commentedI had to use workflow 7.x-2.3 instead of the latest version because of this issue, it would be really nice if we can get this thing fixed and have the patch applied to the latest recommended version.
Comment #16
johnvForget my comment #10. the patch in #9 is fine. I'll commit something shortly. This is a regression issue, as doxigo nicely points out. Thanks doxigo. It helped finding the root cause.
Comment #18
johnvThis is now fixed using #8. The problem was a change that was OK for Workflow Field, but broke Workflow Node.
Comment #19
rbrownellThank you johnv!
Comment #20
doxigo commentedThank you john for fixing it
Comment #22
pianomansam commentedThis issue is still found in 7.x-2.4 and has only been committed to 7.x-2.x, so I'm updated the version information to reflect that. Otherwise, someone might repeat the mistake I just made in thinking that 7.x-2.4 doesn't have this bug when in fact it does.
Comment #23
johnvWell, yes. It is hapenning in 2.4 and fixed in the next available version.
Comment #24
pianomansam commentedI realize that it's happening in 2.4. But the standard way of handling bug reports on Drupal.org is to advance the bug report to the latest release it is reported in. In this case, it is 2.x-dev