Rules Integration Support

I haven't looked at this patch yet. So I'm not sure how it compares to the patches started in the related tickets you mention.

Testing the machine name patch and reporting any problems will help push the rest forward since Rules/Actions/Triggers will work a lot better if moderation state and transition names don't change out from under them.

#1226688: Rules Integration Support

Subscribing

sub

sub

sub

subscribing

subscribe thx!

I am not sure if the label "Content is Live" is a good way of describing the state. By that I mean I haven't seen the phrase being stated before. Is there a more general used way of saying this in Workbench?

I think WB calls that "Published".

+++ b/workbench_moderation.rules.incundefined
@@ -0,0 +1,98 @@
+
+  return workbench_moderation_node_is_current($node);
+}

This will not return the live version, it will return the current version.

+++ b/workbench_moderation.moduleundefined
@@ -1400,6 +1400,10 @@ function workbench_moderation_moderate($node, $state) {
+  if (module_exists('rules')){
+    rules_invoke_event('workbench_moderation_after_changing_state', $node, $new_revision);

This is called even when the state haven't changed, is this intended behavior?

Was having some issues but changing:

+
+  if (module_exists('rules')){
+    if ($new_revision['from_state'] !== $new_revision['state']){
+      rules_invoke_event('workbench_moderation_after_changing_state', $node, $new_revision);
+    }
+  }

To:

+
+  if (module_exists('rules')){
+    if ($new_revision->from_state !== $new_revision->state){
+      rules_invoke_event('workbench_moderation_after_changing_state', $node, $new_revision);
+    }
+  }

Solved them, will roll a patch after reviewing further.

Have a patch incoming fixing that and adding another condition.

will post it as soon as I figure out how to actually create the patch file :)

Here's the patch, fixing the issue with objects vs. arrays.
And adds a "Contents current state" condition which allows to check for what state the node is after it's updated.

This is great, thanks guys was just about to start having a go at doing the same thing!

subscribing

+function workbench_moderation_set_state_rules_action($node, $moderation_state) {
+  if (is_object($node) && !empty($moderation_state)){
+    actions_do('workbench_moderation_set_state_action', $node, array('state' => $moderation_state));
+  }
+
+  return array('node' => $node);
+}

Why aren't you using workbench_moderation_moderate($node, $state); to change the state? just like it is done in the function workbench_moderation_moderate_callback()?
It seems a little off topic to implement the action_info hook, especially when there is another issue here already working on implementing it.

Since work is happening also on integrating Workbench Moderation with the Trigger module (#1079134: Add triggers when states are entered/exited), perhaps that and the Rules integration should use a common interface (like a hook). I submitted a patch to that issue's queue that adds a hook that fires after a node is transitioned from one state to another. This patch should probably use that hook as well.

subscribing

#20: workbench_moderation-1226688-20.patch queued for re-testing.

I see several patches in this thread, with some having been superseded. What is currently the order to apply patches to workbench_moderation 7.x-1.0?

It looks like this order ?
1 http://drupal.org/files/issues/workbench_moderation-1226688-20.patch
2 http://drupal.org/files/issues/trigger_support_for_wb_moderation-1079134...
3 http://drupal.org/files/issues/workbench_moderation-1226688-29.patch

Thanks for working on this!

I get AJAX errors when trying to use the following Rules components:

* Content is live revision (condition)
* Contents current moderation state (condition)
* Set moderation state (action)

I did add a new workflow state ("Archive") before trying this, but I don't think that should have mattered.

I'm unable to quite get GIT to work, but I would love to apply this patch.

I've created the file: workbench_moderation.rules.inc in the workbench moderation module folder, and i've included the patch contents (though stripped to only include important code).

How do I let drupal know it's there now so Rules can access it?

subscribing

Subscribing

Subscribing (last one? ;-))

I just tried the patch provided and did not get any error... Itangalo > which version of rules are you using ? (I'm using 7.x-2.0)

#39: I'm using dev, but if the bug is gone now I expect that it will be gone in dev as well.

Here is a new patch taking both patch 32 and patch 29.

Itangalo > Can you try with rules 7.x-2.0 ?

Patch tested! The AJAX errors in #33 are no longer present. Yay!

Also tested and works fine! Commit to dev version?

Patch from #41 had 2 whitespace errors.. removed them manually (line 33/34)

Hi all,

thanks for the patch. For now the only condition I see in the Rules UI is the node's current state, I would love to see the previous state (see enclosed image), so we can trigger to action through Rules only when we're moving from one specific state to another.

That might be for a different feature request though.

If I understand the patch correctly, the only way to access the previous state and do something is by creating a custom module, right, and not through the UI, right?

Cheers,

Albert.

Also, small typo: "content's current moderation state" and not "contents current moderation state". (notice the apostrophe).

#45: yes, "previous content state" is absolutely desireable to have as an option there. Important.

@thekevinday,

the patch at #48, contrary to the one in #44, does not contain any reference to the workbench_moderation.rules.inc file, perhaps you forgot to add it to the patch?

Thanks,

Albert.

Nice work, works great for me. I added the patch, and created a rule that shows the message "Be careful, you are going directly from Draft to Published!", only if the previous state is draft and the current state is published.

It worked great, thanks,

Albert.

Also tested the patch and it works fine!

Patch works great for me too...

Works for me too

Hi,
unfortunately patch does not work for me. We did install the most recent patch via GIT and it applied successfully but no new events are available in Rules (using newest workbench dev. version).

We also tried to install the trigger_support_for_workbench_moderation - 39 first. But the patch does not apply successfully and it throws the error-message: "error while searching for: return $output".

Can you help us how to install the patch rules integration patch successfully?

Thanks in advance!

@zweistein_13 use the latest dev version of the module, patch using -p1, manually check that you patch has actually applied, then clear all your caches. Please provide the URL and a screenshot of the page where you expect to be seeing something you're not.

Works great!

Hi, made a condition too for workbench moderation, unfortunately I missed this topic :)

I'm seeing that some of my code is different, but maybe it may be helpfull. I used a list so you could select multiple states as a condition.

Thanks, cheers!

*damn, can't add files after you save the reply :)

/*
 * Implements hook_rules_condition_info().
 */  
function workbench_moderation_rules_condition_info() {
  $defaults = array(
    'parameter' => array(
      'node' => array('type' => 'node', 'label' => t('Content')),
    ),
    'group' => t('Workbench'),
    'access callback' => 'rules_workbench_moderation_node_integration_access',
    'module' => 'workbench_moderation',
  );
  $items['workbench_moderation_state_is'] = $defaults + array(
    'label' => t('Workbench state of content'),
    'help' => t('Evaluates to TRUE if the given content is of one of the selected content types.'),
    'base' => 'rules_workbench_moderation_state_is',
  );
  $items['workbench_moderation_state_is']['parameter']['states'] = array(
    'type' => 'list<text>',
    'label' => t('Content new workbench moderation state is'),
    'options list' => 'rules_workbench_moderation_states_options_list',
    'description' => t('The Workbench state(s) to check for.'),
    'restriction' => 'input',
  );
  return $items;
}

/**
 * Node integration access callback.
 */
function rules_workbench_moderation_node_integration_access($type, $name) {
  if ($type == 'event' || $type == 'condition') {
    return entity_access('view', 'node');
  }
}

/**
 * Provides the content type of a node as asserted metadata.
 */
function rules_workbench_moderation_state_is_assertions($element) {
  return array('node' => array('bundle' => $element->settings['states']));
}

/**
 * Options list callback for workbench moderation states.
 */
function rules_workbench_moderation_states_options_list($element) {
  $labels = workbench_moderation_state_labels();
  $array = (!empty($labels)) ? $labels : array();
  return $array;
}

/*
 * Condition: check for new state revisions of the node.
 */
function rules_workbench_moderation_state_is($node, $states) {
  $node_new_state = (isset($node->workbench_moderation_state_new) && $node->workbench_moderation_state_new) ? $node->workbench_moderation_state_new : '';   
  return in_array($node_new_state, $states);
}

One thought about this: the "previous" and "current" state conditions should accept more than one input. Consider the following scenario (as is the case on my site):

- content can be deemed "important"
- content can be deemed "politically sensitive"
- content can be deemed "politically senstive and important".

All three of the above contents must be approved by someone with the role "supervisor", and then set to "needs review" for grammatical corrections.

If I want all my content that transitions from either "important" or "politically senstive and important" to "needs review" to be set to "sticky at top of lists", this can be done with this patch, but only by creating two rules. It would be nice (if not too complex) to be able to do it with one rule: to be able to set the "previous" state to EITHER "important" OR "politically sensitive and important".

I will leave this issue at RTBC, because it's still possible to achieve this currently, and once it's in perhaps another issue might be opened.

Sorry, I'm begginer here, should I download and apply all of the patches or just the last one for use these integration features ?

I tried with the rules_integration-1226688-50.patch on the last dev version of the module but I still can't find filters like :
- Content is live revision
- Content moderation current state
etc.

thanks

@dams_26, it should work. You might want to try clearing your Drupal cache under "Performance".

Good luck,

Albert.

@alberto56 And it work's, thanks!!!

Thank you for this awesome feature, you're doing a great job.

After a bunch of confusion about which patches to apply, I was able to get rules integration working with the most recent dev version and the patch from #50 only, without any of the trigger patches. It's working so I'm assuming I did it right! Thanks for all the work on this great feature, hope it gets committed soon.

#50 - worked like a charm!!!

So I'm curious if the maintainer has any opinion on this patch.

I'm currently running a very small modified version of this patch which probably makes sense to separate into a separate issue.

I think the addition of the hook_workbench_moderation_transition is more important than rules support. Also if that hook gets added the rules support can be done in a separate module is needed.

Essentially what I'm saying is +1 hook_workbench_moderation_transition().

As a side note I did test this patch with rules and it seems to work well but I wont mark it RTBC because I didn't really do a thorough rules test.

I agree on the importance of hook_workbench_moderation_transition(). I often find Rules is complete overkill and adds far too much UI cruft for the sort of thing I want to do, which is generally better accomplished in my own custom module hook implementation.

So +1 from me on a patch that just supplies a hook for other modules to implement, and +1 on moving Rules integration to a separate module.

There's a problem with invoking hook_workbench_moderation_transition() solely where it is now (in the patch at #67).

It can run before the state transition is actually saved to the DB. If the node already has a published revision, the node_save() operation will be deferred from workbench_moderation_moderate() to a shutdown function, workbench_moderation_store(). So the hook needs to be invoked from there, and also conditionally from workbench_moderation_moderate().

This patch does that, incorporating the entire patch from #67.

I have tested this with my own custom module which loads data from {node} in an implementation of hook_workbench_moderation_transition() - this now works correctly, acting on the state-change regardless of whether the node had a published revision.

I have not tested if this change affects Rules functionality in any way, though I expect that it was in fact broken before, for the same reason.

Sounds like we need two hooks, doesn't it?

hook_workbench_moderation_transition($node, $old_state, $new_state)
Called at the end of workbench_moderation_moderate(), exactly as for #67, unaffected by the published condition, before the live revision (if any) is saved. This hook will always fire.

hook_workbench_moderation_live_revision_save($live_revision, $transitioned_revision, $old_state, $new_state)
Called from the shutdown function, after the live revision is saved. This hook will only fire if there is already a live revision, ie it will not fire when a node is first created as draft, or as a draft moves through additional states before it is first published.

I'll test this and supply a new patch.

Patch as per #73, reverts to behaviour from #67, adds a new hook when the live revision is saved.

Rules integration does not implement the new hook, but that might be a desirable addition?

Further testing suggests I'd need to implement both hooks anyway, in which case it's better to just register my own shutdown function from hook_workbench_moderation_transition() - this will run after the node_save() since it's registered later.

And some thought about the idea of invoking hooks from a shutdown function leaves me a little uneasy, perhaps that's not a good thing to be doing?

In which case patches #70 and #74 should be ignored, I'm good with #67.

I'm wary of adding the hook invocation in a shutdown function, though I couldn't find any guidelines about that anywhere?

Assuming doing so is OK, the documentation should state that the hook is invoked when the state transition is complete, and that there may have been a deferred node_save() in a shutdown function, depending on whether there is a published revision. If a module's hook implementation needs to know whether it has been invoked pre-save or post-save (from shutdown), it needs to check isset($node->workbench_moderation['published']), which is the condition used to determine whether the hook is invoked from the transition or from the shutdown function.

Personally I think two hooks would be clearer, and perhaps one would have 'shutdown' in its name?

But I'm still good with #67, and that's easily documented - if you have code that must run after the possible node_save(), check the 'published' condition and register your own shutdown function.

This might at least provoke some thought and help stop cut-&-paste developers doing inadvisable stuff from a shutdown function, one that they won't know they're running inside if they blindly implement the hook in #70.

#67 is working well for my needs.

I'm a nubie trying to implement an email action to a set of publishers triggered by various page modifications. I applied the patch from #70 post, but I don't see where I can set/create the events for workbench rules. I really need to get this action in place soon, can someone provide some assistance?

I've tested #67 on an in-progress site and it seems to work well. I'd be comfortable with committing #67 and addressing the question of of a shutdown hook in a follow up issue.

I'm attaching the patch I'm running on the aforementioned site. It also includes a 'workbench_moderation_set_state_during_save' action that I'm using in conjunction with feeds importing. I'm varying the moderation state based on some arbitrary conditions on the imported node and this seemed most easily accomplished by directly setting the workbench_moderation_state_new property.

For the purpose of clarity I think it'd be better to commit #67 and then address workbench_moderation_set_state_during_save in a follow up issue.

Kevin, John, anyone else, objections?

No objections from me, I have #67 running fine on a live site.

I don't think a shutdown hook is needed, if the docs for this hook point out that a node_save() may occur later and to handle that the implementing module can register its own shutdown function.

Great, commit to come in a few minutes.

Thanks again for your work on this: http://drupalcode.org/project/workbench_moderation.git/commit/05427321d0...

Awesome!

Coincidentally, the new hook added in this commit allowed me to write a patch to fix a Superfish problem: #1484064: Nodes published through Workbench Moderation don't show in Superfish menu until caches cleared.

I'm not 100% sure it's a superfish issue, though -- could anyone here take a look at my patch and weigh in on that issue, please?

#67 worked well for me

Just tried the patch from #80 against 1.1 and setup rules and an email notification, and it works perfectly. Nice work guys. Hope this gets committed to the repo.

The patch has been committed to 7.x-1.x

This is fantastic. Thank you.

If anyone is needing to unpublish using rules, I have a patch for that: #1593792: Add 'unpublish' action to available rules actions

I found a small bug, where the node object does not yet have a workbench_moderation property on first save, but does have a 'workbench_moderation_state_current' property set. The attached patch handles that scenario.

Is this the right place to post, or should I open a new issue?

#93 I'd recommend to create a new issue, so that your patch can be tested, worked out and ported to next workbench moderation release. If this problem is coming from this patch, you may just link in the new issue to this one. Thanks for your work!

Thanks @maxelli. I've created a new issue at #1605252: Fix minor bug with STRICT error reporting when using Rules Integration

I don't know if this is the right place to ask, so I apologize in advance if this is the wrong place.

However, can I request to add a new action based on a moderation state? I'd like to lock a node from editing to certain roles depending on its current moderation state.

Hi vchen, just create a new issue with category "feature request". I think what you need is not an action but a feature where you can set permission restrictions for states. If you are familiar with programming drupal modules, you may take a look at hook_permission() and hook_node_access(). If not, just open a new issue.

Replaced direct links to issues with automatically generated ones.

RulesEvaluationException: Argument previous_state is missing. in RulesPlugin->setUpState() (line 717 of /sites/all/modules/contrib/rules/includes/rules.core.inc).

Content created by features call "after_moderation_transition" event and return this error.

Here's a fix for #101 comment. For some reason $node->workbench_moderation['my_revision'] becomes array, not an object.
Then $old_revision->state returns as 'null'.

I'm not sure why the revision data can be in array form -- fixing that at the source seems like the proper fix -- but in the interim it seems like ALL of the revision data is expected to be in object form, so this is an alternative to #102 which does that.

#101 seems to be the result of feature_ver_export exporting an array and treating it as, common when used with webform_features module.
I issued a follow issue with a new patch: #3090038: Rules Error caused by $node->workbench_moderation being a bunch of arrays, not objects