Closed (fixed)
Project:
Webform Rules
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Apr 2012 at 02:40 UTC
Updated:
30 Mar 2013 at 09:30 UTC
Jump to comment: Most recent file
Comments
Comment #1
stborchertI 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
Comment #2
ultimikeStefan,
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
Comment #3
mengma commentedThis patch seems very useful
Comment #4
stborchertI've created a patch that extends the selection to either a loaded node or webform names.
Comment #5
ultimikeStefan,
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
Comment #6
stborchertI've tested this right now and the parameter
$nodeisNULLwhen leaving the field empty.Here is an export of the rule I'm using:
I've added some logging to _webform_rules_webform_set_status:
which outputs
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:
Users should be able to select both, a loaded node and manually selected webforms.
This is totally wrong here. Try selecting 2 webforms with your patch apllied and you'll see that only the first one is processed.
Comment #7
ultimikeStefan,
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.
Thanks,
-mike
Comment #8
stborchertOk, 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.
Comment #9
stborchertUps, patch was not correct (has been made based on some code that has been staged already).
Comment #10
ultimikeStefan,
Sorry I've been out of the loop this week - I'll test the patch this weekend and get back to you.
Thanks,
-mike
Comment #11
ultimikeStefan,
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
Comment #12
stborchertCommitted to 7.x-1.x-dev: