Add triggers when states are entered/exited

This is a very rough first stab. It adds a single trigger at transition state change and exposes two new tokens, [moderation:new-state] and [moderation:old-state]

Awesome! I have to put in my 2 cents as Token maintainer. :) I'm not exactly seeing the purpose of a new token type when this seems to be a node-related token. I'd advise adding the tokens into $info['tokens']['node'].

I'd agree. The "purpose" was that this was the first time I'd ever touched the token API and I ran into some weird newb issues when I tried merging them into the node tokens.

Adds a token for the editor username.

And the patch sans typo...

Loving the trigger patch, I didn't apply the token patches but the trigger will not show up in Rules, it shows up in the Drupal triggers, just not in rules. Would love to know if there is anything I need to do to get it in Rules (I know this isn't Rules support, just curious if you know anything.)

subscribing

subscribe

Subbing

Subscribe

I've been testing the patch in #10 with 7.x-1.0-beta8 and with the default moderation states to send out an email when the state changes. Works well without any problems for me.

I re-rolled patch #10 with some changes to account for the 32 character limit for trigger hooks. If any trigger hook exceeds 32 characters, I created an MD5 hash to use as the trigger hook string. The hash is done when creating the trigger assigning and when getting the trigger assignment to ensure they will match.

I've tested the patch from #17 with custom workbench states and everything works fine. Just wondering, why there is no rules integraton?

ive tried the patch #17 on 7.x-1.0-beta8 but my email action returns the tokens just as [workbench_moderation:from-state] however it works for token [node:title]. is there anything i need to configure to allow these tokens to evaluate ?

but i am successfully able to evaluate wbm using these node tokens

[node:wbm-my-revision:editor:mail]
[node:wbm-current:editor:mail]

but with User Warning errors

User warning: Attempting to perform token replacement for token type workbench_moderation without required data in token_tokens() (line 791 of /sites/all/modules/token/token.tokens.inc).

rbishop, this patch doesn't add any new tokens or touch token support in any way. Token support was split out into a separate issue: #1159256: Token support for workbench moderation states

The #10 and #17 patches cause saving an edit to fail when the Trigger module is disabled.

PHP Fatal error: Call to undefined function trigger_get_assigned_actions() in /Library/WebServer/Documents/workspace/drupal/sites/all/modules/workbench_moderation/workbench_moderation.module on line 1850, referer: http://localhost/workspace/drupal/?q=node/1/edit

We need to check module_exists for trigger when calling workbench_moderation_trigger_transition()

  if (module_exists('trigger')) {
    workbench_moderation_trigger_transition($node, $old_revision->state, $state);
  }

subscribe

Thanks Eric. Patch modified to include conditional around trigger from comment 21.

sub

subscribing

sub

Absolutely fabulous, thank you!

#23 patch works perfectly :)

#23 works me too. Set to RTBC. Thanks!

I know this has been RTBC, but it seems like the better way to do this would be to implement a hook that fires when a transition occurs, then bind the trigger call to that hook. As it stands, you sort of force yourself to duplicate a lot of code when adding hooks, triggers, and rules integration. Instead, it would make sense to make trigger integration just another consumer of a consistent workbench moderation API, of which rules could be another.

How do people feel about this approach? Obviously, it should probably be part of a bigger discussion on a uniform Workbench Moderation hook API, but it seems pretty reasonable to me.

(Patch applies to current master branch).

Re-rolling against 7.x-1.x.

Sigh. Trying again.

It makes sense, as you said, to centralize the changes.

Heres what I did:
- Fixed spelling of trasnistion at line 1875.
- Moved the '*_action_info()' functions I created here http://drupal.org/node/1226688#comment-4989010 to this function.
- Moved the "if (module_exists('rules')){ ..." code to your workbench_moderation_workbench_moderation_transition() function in this patch.
- Used your "Add a trigger for each transition." loop code to associate an action with each of those triggers.
- I also associated 'node_presave' with the actions as well.

Great work, this is exactly the sort of functionality I need.

I'm newish to Drupal and have a general question about this process.

When this patch is completed will it become part of a re-released Workbench module or an automatic update?

Basically if I want to use this functionality do I watch this log and wait for the patch to be finalised and then install it?

Thanks for your work. I think this community approach to development is fantastic (as is Drupal).

@kingswoodute - This is open source, I would and I am going to git clone the dev version and patch that sucker now! The odds are it will be included along with other patches in the next stable release. Then you just update to that.

Happy Drupalling!

This seems to be problems in how workbench_moderation is designed.

There are a number of issues in how it is designed that prevents some of the functionality here from being used.

One is the usage of node_save().
I had this same problem with workbench_access when writing actions support.
The only solution was to provide presave only actions and not any node_update or node_insert actions.
What happens is node_save will trigger another set of actions.
When using an action that responds to a node save and then it itself will do a node_save, well you can guess what happens.
By using presave functionality, changes are made to the properties and no node_save is made.

For the other issue, it seems that some part of how workbench_access is designed is causing a duplicate revision to be saved under all circumstances on initial node creation.
I tested this by making a number of the workbench_moderation functions do a return; as the first line of code.

I suspect that this could be a problem that both workbench_access and workbench_moderation are doing manual node_save() operations, which means a node_save() gets called 3 times for any given node.
One for the original node_save, one for workbench_access, and one for workbench_moderation.

I suspect the solution to this would be to not perform any manual node_saves and do any work on fields like it is done with presave.
As an alternative, perhaps the workbench module could provide a node save wrapper function that can call all workbench-specific node save operations to at least reduce the number of node_save calls?

Hey ! Great works !
This patch works perfectly.

I have 2 questions thought :

- I'm currently using the custom module 'Action Email Role' (http://drupal.org/node/1213306) which let us create an action for sending an email to all users of a given role. This module works with 'Node', 'System', 'Taxonomy' and 'User' triggers section, but not with the 'Workbench Moderation'. Actions of that type don't appear in the list. Any idea of why ?

- When a moderator approve or refuse an article, I want the user who write the new version of an existing article to be notified. How can we specify in the action that the receiver is the User who write a new version of the article instead of the original author ? I can't find the correct token for that.

Thank for your help.

This patch works perfectly.

I wish that were true.

Actions of that type don't appear in the list. Any idea of why ?

Yep.
Actions seem to require one to specify the "trigger" type to associate it with.
See: http://api.drupal.org/api/drupal/modules--system--system.api.php/functio...

Which means that each an every module must know about another to add itself to associate it with anothers triggers.

I suggest using the rules module, it is better at doing these things than the core trigger system.
Of course, because it can do more it might be harder to learn how to use. I suggest applying the patch https://drupal.org/node/1226688 after applying this one.

Here is the new patch with the node_update and node_insert removed for the time being.
I added a presave action to work with presaves and it can be used to set states.
I am not sure how useful the presave can be for triggers+actions, but it at least shows how not performing a node_save() works better.

sub

Thank you thekevinday !
Using rules instead does what I want.

Any suggestions for my 2nd problem ? How to send an email to the User of the new version ?
Another way could be changing the content owner when he saves his draft.
Is it possible to do that ? With VBO ?

I had no time to test the newer patches, but I want to tell you that the patch in #23 may cause a new bug (not sure): http://drupal.org/node/1230034#comment-5111200

No, the problem is not with the patches, it is a token module bug: #1317926: menu_tokens function should not change the node object

thekevinday, i wanna say 10000000 thanks.
I'd say this is a typical feature a workflow module must have.

Wish you a good day.

Just for the record, all these people created/modified the patch:
binford2k
stevector
nrambeck
theunraveler

I was simply the last person to make any changes.

Thanks for this feature you did a great job. Can we hope a new release of the module soon?

#39: trigger_support_for_wb_moderation-1079134-39.patch queued for re-testing. ===> sorry, is there anyone who can delete my post ?

Don't know if this is a bug, but presave action does not set the state to 'published' when moderating the state to 'publish', only node->state is set to 1. when using workbench_moderation_set_state_action the status is set to 'published' then. I can set every other status with the presave action, like 'draft' to 'needs review', but publish does not work. rules are set correctly.

me again. i don't know if your patch from #39 works as it should. I use the actions as VBO's, like selecting multiple nodes an set new state per one click. So for that use case, my post #49 already mentioned:

neither presave action nor the normal set moderation state action do what i want.

the normal method: status isn't updated after set it via vbo. I see in list of recent version the old state. Clicking on the node itself, theres the new state. This is not a caching problem as i found out.

Presave action: it saves some states, but when set the state to publish -> state is not being set & only node->status == 1.

So I have altered your last patch, removing presave action because i don't really know what it is for, but the normal set method has been changed. This patch is working for me, with version 7.x-1.1 and using node revision views.

here's the snipped of the changed function code:

<?php
/**
 * Changes the moderation state for a given node.
 */
function workbench_moderation_set_state_action($node, $context) {
  if (!empty($context['state']) && _workbench_moderation_moderate_access($node, $context['state'])) {
    $node->workbench_moderation_state_new = $context['state'];
	workbench_moderation_moderate($node, $node->workbench_moderation_state_new);
    watchdog('action', 'Change node %nid moderation state to %state.', array('%nid' => $node->nid, '%state' => $context['state']));
  }
}
?>

posted patch in attachement.
please test it out, maybe it fits your needs in VBO.

If this patch is useless, please remove this post. thx.

Great!

Thanks for your work

Shouldn't this be set to "needs review" for the latest patch?
Or has this integrated into the dev branch yet?

Just a note, it looks like most of this patch was already committed in #1226688: Rules Integration Support, although it sounds from the discussion there like there may be some additional follow up work to do?

#54: Do you know if patch from #1226688: Rules Integration Support also support actions to use for example in VBO? I don't know what the patch there does exactly now, just set a rule for the trigger like "After stat X was set", or if there are also actions like "set moderation state" supported. If so, this issue here is a duplicate.

I believe there are actions too - it looked like it was almost literally the same patch as the latest one here (with a couple small tweaks on top of it), plus an extra file for the Rules integration on top of that.

I didn't look too carefully into it, but it sounded like there was some discussion that followup was necessary and that this issue could be used for that followup, but otherwise I agree this issue is probably fixed.

Just looked into it. It does, so I close this one.
Issue from http://drupal.org/node/1226688 fixed this issue.
Thanks David_Rothstein for getting this clear.