Comments

stborchert’s picture

I don't think we need to define an additional action to simply open or close a webform. This can be done easily using the action "Execute custom PHP code" so I see no real benefit in adding this action.

If the action would be extended, e.g. by selecting the webform to open/close (note the wording difference to be in junction with the wording from Webform ;) ) this could be something to add.
Example: https://img.skitch.com/20120418-84k3wcxqarm4ki3upn68ufbfis.jpg

ultimike’s picture

Stefan,

Allow me to respectfully disagree - here's why...

First and foremost, if we can help people avoid directly entering raw PHP into the Drupal UI, we should. Granted, the enable/disable webform action is quite simple, but for people who aren't comfortable with PHP, this action would be very helpful. In fact, this patch came about because I was teaching a workshop yesterday where we were trying to build a rule to disable a webform at a specific date/time and it wasn't possible without writing PHP - of which very few people in the workshop were familiar with.

Secondly, I was going down the road you mentioned in the screenshot (select the webform to enable/disable), but for my use case, I actually need to schedule the enabling and disabling of the webform. By leaving the webform selector out, I made it a bit more flexible by it being able to accept a webform as a parameter.

Thoughts?

Thanks,
-mike

mengma’s picture

This patch seems very useful

stborchert’s picture

Status: Active » Needs review
StatusFileSize
new4.88 KB

I've created a patch that extends the selection to either a loaded node or webform names.

ultimike’s picture

Stefan,

Thanks for working with me on this, it is much appreciated.

I worked with your patch a bit today, and made a few changes/fixes, but I think there is still an issue with it though. Now that we have 2 optional parameters in the webform_rules_rules_action_info() action, we're getting some odd behavior in the _webform_rules_webform_set_status() function. Even if the "Webform" data selector in the action configuration page is left blank (so that a webform can be selected from the "selected_webform" list), there is always a $node passed in to the _webform_rules_webform_set_status(). I put an if-statement into this function so that if a $node is passed in, then it is updated and saved, otherwise the $selected_webform is saved (via the code you added). In _all_ cases that I've tested, there is _always_ a $node.

Thoughts?

Thanks,
-mike

stborchert’s picture

Status: Needs review » Needs work

there is always a $node passed in to the _webform_rules_webform_set_status()

I've tested this right now and the parameter $node is NULL when leaving the field empty.
Here is an export of the rule I'm using:

{ "rules_close_webform" : {
    "LABEL" : "Close webform",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules", "webform_rules" ],
    "ON" : [ "cron" ],
    "DO" : [
      { "entity_fetch" : {
          "USING" : { "type" : "node", "id" : "1" },
          "PROVIDE" : { "entity_fetched" : { "entity_fetched" : "Fetched entity" } }
        }
      },
      { "webform_close" : {
          "node" : [ "" ],
          "selected_webform" : { "value" : { "webform-client-form-3" : "webform-client-form-3" } }
        }
      }
    ]
  }
}

I've added some logging to _webform_rules_webform_set_status:

<?php
function _webform_rules_webform_set_status($node = FALSE, $selected_webforms = array(), $open = TRUE) {
  error_log(var_export($node, 1));
  error_log(var_export($selected_webforms, 1));
  // ...
}
?>

which outputs

NULL
array (
  'webform-client-form-3' => 'webform-client-form-3',
)

As you can see in the rules export, I'm explicitely loading a node before calling the close action. Even then the parameter is NULL.

Patch review:

+++ b/webform_rules.rules.inc
@@ -100,6 +170,59 @@ function webform_rules_condition_webform_has_id($form_id, $selected_webform) {
+    return true;
+  }
+  else {

Users should be able to select both, a loaded node and manually selected webforms.

+++ b/webform_rules.rules.inc
@@ -100,6 +170,59 @@ function webform_rules_condition_webform_has_id($form_id, $selected_webform) {
+        return false; // so that the automatic Rules entity save doesn't occur (http://drupalcontrib.org/api/drupal/contributions%21rules%21rules.api.php/function/hook_rules_action_info/7)

This is totally wrong here. Try selecting 2 webforms with your patch apllied and you'll see that only the first one is processed.

ultimike’s picture

Stefan,

Ah - understood. I was assuming that it would be an either/or thing. Either the $node passed in would be opened/closed or the $selected_webforms would be open/closed. I completely understand why it would be fine if we handled both.

Regardless, check out my Rule below. It uses a different action and demonstrates what I was trying to explain in my comment 5 above.

{ "rules_morning_test" : {
    "LABEL" : "Ultimike Open Webform Test",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "webform_rules", "rules" ],
    "ON" : [ "node_update" ],
    "DO" : [
      { "webform_open" : {
          "node" : [ "" ],
          "selected_webform" : { "value" : { "webform-client-form-8" : "webform-client-form-8" } }
        }
      }
    ]
  }
}

Thanks,
-mike

stborchert’s picture

Status: Needs work » Needs review
StatusFileSize
new6.31 KB

Ok, I think I've got it. Some events (as "node_update") are providing variables named "node" (which contains the current node object). Because I named the parameter of the actions "node" too, this parameter is filled automatically by rules even if it has been left blank in configuration.
Renaming the parameter fixed this.

stborchert’s picture

Ups, patch was not correct (has been made based on some code that has been staged already).

ultimike’s picture

Stefan,

Sorry I've been out of the loop this week - I'll test the patch this weekend and get back to you.

Thanks,
-mike

ultimike’s picture

Stefan,

Your patch looks just about perfect - I found one minor issue in the webform_rules_webform_statuschange_validate() function, an updated patch is attached.

Thanks for your patience.

Lemme know.

Thanks,
-mike

stborchert’s picture

Status: Needs review » Fixed

Committed to 7.x-1.x-dev:

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.