workflow-state tokens are reversed

I believe I've finally found a fix for this bug. The problem lies in the workflow_token_values function, which always replaces tokens with values from the database. In this case, however, it should be using values from the node-edit/workflow form. I've attached a patch that makes it use the proper values when a node is being submitted. I hope this fix makes it into the next release!

I seem to still have a problem when I try to use the tokens after saving new content. I created a new content type "Estimate" and mapped it to a workflow "Project". Unfortunately, when I create an action in the rules module to send an email on the rule: "After saving new content" with a condition that the content type be equal to "Estimate", the tokens:

[node:workflow-current-state-name]
[node:workflow-old-state-name]

returns an emptry string. However, when I create a rule "After updating existing content" with the same condition that the content type be equal to "Estimate", I get the tokens replaced just fine.

If you know why this is happening, I would surely appreciate the help.

@mrtm3050: By design, [node:workflow-old-state-name] should return an empty string since the node has just been created and there is no "old" state. As for [node:workflow-current-state-name], you are right: the current version of the Workflow module incorrectly returns an empty string. My patch in #2 fixes this issue, according to my tests.

Where can I find your new patch? Is it the same one linked above?

Thanks for your help.

I'm sorry, I understand your comment now referencing comment #2 for the patch. I actually applied this patch am still having the same problem. The rule for "Updating existing content" replaces the token [node:workflow-current-state-name] after I update content, but the rule "After saving new content" does not replace the token [node:workflow-current-state-name], and this is after applying your patch.

I just realized that I havent tried the one thing I should have done in the first place, which is to download the newest version of workflow (I am at version 6x-1.0-rc3 and I believe the newest version is 6x-1.1), then I will apply your patch again and see if this fixes it.

Thanks again.

Still have the same issues, the rule:

"After saving new content" doesnt replace the token: [node:workflow-current-state-name]

while the rule:

"Updating existing content" replaces the token [node:workflow-current-state-name] just fine.

I am using the latest version of workflow (6x-1.x-dev).

Any help would be greatly appreciated.

Raj

@mrtm3050: Make sure you are using the latest version of the Rules module (6.x-1.0-beta5). Also, if you could export the rule that is causing you trouble and post it here, I can help you further.

I found the problem, its actually pretty interesting.

It all happens in workflow. I created a near identical workflow and mapped it to the News content type. The problem occurs when I give the author of the content the ability to only move to one state. That is, if I am the author of new "News" content, and I'm only allowed to advance to the Unpublished state, then the token does not get replaced. This is because when I create the content, I dont see an option in the "Create News" menu to change states, in fact, there is no menu whatsoever of what state I am on. When I click submit, I assume that the database just does not get populated. The state that you advance to is done automatically because there is only one state to move to, in this case, the Unpublished state.

However, when I allow the author to either advance to the Unpublished state, or the Published state when creating a "News" item, then you see the workflow state options in the "Create News" menu. You can select between the Unpublished state, or the Published state, fill out the title of the news article, body, then when you click submit, the rule is executed and the email is sent. Most importantly, the [node:workflow-current-state-name] gets replaced, I assume because the workflow state options were in the "Create News" menu and the database was populated with the state selection made by the author.

I used the exact same rule in both cases, one worked, and the other did not. So it has something to do with how the workflow is created and the number of states the author is allowed to move to from the "creation" state.

Good work, mrtm3050!

With respect to my previous patch, I failed to take into account the possibility of there being no value from the node-edit form with which to set the token value. I've attached a patch that adds this functionality and also makes the [node:workflow-old-state-name] token return "(creation)" when the node is being inserted. I know this contradicts my statement in #4, but I think most users will find the new behavior to be much less ambiguous.

As a side note, after looking into your problem some more, I found another bug that contributed to your difficulties to some extent. If it had been fixed, my original patch would have worked for you. I went ahead and created a separate issue for this new bug: #400434: Corrupt hidden input on node-edit form. You can go ahead and apply my patches for both issues if you'd like, but the one attached here should be enough to fix your particular problem.

This is great... I was trying with this for a long time. I can confirm this is working and hope it is committed as soon as possible as without it workflow and rules are not working together. Thanks prof1337 and mrtm3050!!

I am using the above method to make textual comparisons to alert people on the site of a change in workflow state. However when I do this using the "Content is going to be saved" option - it means that even if the workflow state is not changed, then the notification is sent. ie. if a user edits the node then because the "Current state is x" and "Previous state is y" then it still gets sent. Does anyone have a method to add the condition "Only if workflow state is changed" somehow?

Any help greatly appreciated... Thanks,

Adam

If I understand your question correctly, Adam, it sounds like you need to add a textual comparison condition to your Workflow-NG/Rules rule comparing "[node:workflow-current-state-name]" and "[node:workflow-old-state-name]". Make sure the rule is negated so an email will only be sent if the current/submitted state is NOT the same as the old state. With the patch from #10 installed, this should give you the result you are looking for. Let me know if this works!

Hi prof1337,

Thanks a lot for the information - I wrote a response but actually it was long and veered horribly off subject, which I think is what the "change of title" below was a referral to so I'm editing that comment to let you know I managed it with a negated condition using current-state on both the saved and unchanged content. Seems to be working just fine - so thanks again.

Adam

This patch also fixed my issue, thanks! I look forward to see it committed to CVS.

Has this patch been commited to the latest dev? It doesn't seem like it.

I have a field which is workflow state. I have populate it with [workflow-current-state-name]. When I change the state of the node, the token does not reflect the current state.. it reflects the previous state.

I found the same... I'm holding off updating the module until this has been committed - is there any news on this?

Thanks... great module - one of the most powerful in everything we do with drupal.

Duplicate #532410: Tokens returning previous states info when using Actions & Triggers

I also applied the patch on my development Drupal. It also fixed my problem.

I looked over the code too, and it seemed okay to me. I ran it through coder, which found no problems.

With 3 users beside the original patch submitter finding this patch fixes the problem, I reckon we are justified setting this patch to reviewed & tested by the community.

I test the patch #10 and all work perfect. I vote for a commit :).

I have also tested the patch and confirm it does what it needs to do.

Do this patch work for Workflow module version 6.x-1.3??????????????????????
Because I have the same problem above mentioned.

Tested. Works. +1 for committing.

Committed. Will appear in 6.x-1.4.

Is this still an issue in 1.5? I note it says 1.4 has the fix but I am still having this issue with my site and I am running 1.5.

When using tokenized sending email, I am always one step behind where it should be.

Thanks,
Paul.

Apologies, this is a mistake on my part. I am using workflow extensions and had the weight set too high. This has been fixed.