Add conditional email sending feature

I'm not sure about the added complexity here, though you are correct it is not currently possible other than using additional processing code. Webform itself doesn't make single checkboxes very well, meaning creating a "Send me a copy" checkbox is a bit difficult to get looking correct, even with this patch. I'm not sure what value allowing textfields or e-mail fields adds to the configuration options. It seems like a user would likely get confused and select both the e-mail component once when selecting the value, then select the same component again for the "only if" option.

I see the value in this addition, but I think we'll need a clearer UI as to what the option is actually doing (and not just by adding more help text). Right now the options don't seem to make sense to me.

The patch also includes a syntax error and a few code style issues:
- +function webform_update_6666) { is a syntax error. The update number should be the next update in the sequence, not 6666.
- Do not abbreviate variable names.
- Use "e-mail" in user facing text, not "email".
- Put a space after "//" in comments: // If a pre-requisite component was selected, send only if it's non-empty.

I like your ideas. This conditional e-mail system could also handily replace select lists with e-mails as keys, which never made a ton of sense because then you end up with people's e-mails stored in the databases and you can send an e-mail to a person based on two different options (like both "sales" and "marketing").

Regarding the single checkbox, please add any thoughts/code to #264181: Creating a single checkbox.

All told, this segment of code would be nearly identical to the conditional logic for components. For consistency we might just use the same interface, even though it's not real great:

subscribe

Loving the new email system in 3.x. I really want to be able to create select lists using keys instead of email addresses (so that I can use keys to automatically select a Message Topic from the list without exposing the email address), and be able to have more than one select option send to the same email address. Not really sure how to accomplish that since the Advanced Processing got nixed. Is there anything I can do to help work towards the third workflow item suggested in http://drupal.org/node/282436#comment-2457156?

Wow. Very powerful module. Agree with akalata. I could really use a module to prevent exposing email addresses on select list keys. It really doesn't make any sense to expose email addresses to spam harvesters on any forms.

We should merge this with #622630: Some themes won't let image insert, sounds like it's a similar issue. It may be the way your theme works or it could be a JavaScript conflict. More likely it's caused by the behavior of the theme, as described in the other issue.

...setting to postponed, because the system auto-closing might give the wrong impression that this is fixed or something.

Thanks klonos, I think I was confused in #7 and was replying to a different issue. This is very much a legit request.

A note that this issue would negate the need for #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters).

What is the status off the original request: Add conditional email sending feature?

It's exactly where this request shows it is. There's a patch that needs work, it doesn't operate on the 3.x version at all. There's currently no work being done on it but it's a valid request that will be worked on eventually. If work were being done on it, it would be posted here.

Subscribe.

subscribe

subscribe

subscribe

Hi

Think the webform module is great and really easy to use, however it would be great if there could be a facility for the user to be sent and automated response to their email address when they fill in the form to thank them for completing it and to summarise the details that they have submitted. It provides reassurance to the user that everything has been received alright.

@Bob3009: You can already do that in Webform. Add an "e-mail" component to the form (so the user can enter their e-mail address), then set up an e-mail to be sent back to them under node/x/webform/emails. This issue is to extend that existing ability to make it so the user can *choose* if they get an e-mail or not, like a "Send me a copy" checkbox. Right now they will always be sent the e-mail regardless.

subscribe

HI @quicksketch

That's great, thanks very much.

I have got the email going to the person submitting the form to work however I am not able to set up an e-mail to be sent back to them under node/x/webform/emails. This path takes me to node/x and just shows me the form itself. Is that because I am still using 6.x-2.10?

Is that because I am still using 6.x-2.10?

Yes. E-mail configuration has completely been changed in the 3.x version of the module. You can do this in 2.x also but it's quite a bit more convoluted.

Not sure why this issue is marked in the 2.x branch, new features are only being added to 3.x.

Thanks for the quick response, I will upgrade to webform 6.x-3.6

subscribe

subscribing

For what it's worth, I'm currently building a bolt-on module (mostly for my own use) with the intent of making the conditional component logic available on email recipient settings form - as suggested by Quicksketch in #3. I'll make the code available here when it's done, in case it's useful.

OK, here's that code. Slap this in your modules folder and turn it on, and the email editing forms should now have a "Conditional rules" fieldset similar to the one found on components.

It works in a fairly brute-force way - before the 'submit' phase it just jumps in, passes through all the webform emails and checks their conditions against the current value of the relevant component: if the email has a condition set, and it doesn't match the value of the component, the email is brutally torn away from the $form['#node'] object and cast to the four winds (unset). Thus when the normal submit handler comes to send out its emails, that one isn't there any more. I guess if I was doing it as a change to Webform rather than an addon module I'd probably incorporate a "send" boolean field and modify the submit handler to respect that.

Ideally I'd also like to be able to set up multiple conditions ("Component X is value Y AND Component A is not value B") but that would introduce differences from the "Conditional rules" setup on the component form - plus, well, it's beyond the requirements of my current project - so I'm leaving as it is for now.

Should this be changed to "needs review" now? Or "patch (to be ported)"? I know it's not exactly a patch, but in principle there's code there that could be ported into Webform...

I usually prefer "needs work" for something like this because it needs to be converted into a patch. "patch (to be ported)" usually means porting between D6 and D7.

subscribe

Just chiming in to confirm that kingandy's moudle/patch in #27 works quite well for me.

Worked for me, thanks =)

Should this get its own module page? Or it it something that might be included in Webform Conditional - or in Webform itself?

I would like for this functionality to be included directly in Webform itself, which is why this request "needs work". Once in patch form I'm more likely to take a look at it and work on getting it integrated with Webform core.

I converted kingandy's module code in #27 in to a patch for master branch in git (I'm assuming thats 7.x-3.x-dev?). I just copied the code from the module to webform in the (hopefully) appropriate places :)

I haven't tested it (thoroughly) at all. I have only made a "Send me a copy"-checkbox for my form (which was the simple use case we needed) and that works correctly for us.

Additionally, I might be able to give this issue some more time if it gets some attention and I get some feedback/direction. Maybe this solution is not the way to go, seems kind of brute force as kingandy mentioned. But I do not know the internals of webform that well to be qualified to make that call.

I applied the patch and ran update.php on a site with rows already present in the webform_emails table.

I got this:

Failed: PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'conditional_data' at row 1: ALTER TABLE {webform_emails} CHANGE `conditional_data` `conditional_data` TEXT NOT NULL COMMENT 'Data about conditions under which to use this email.'; Array ( ) in db_add_field() (line 2781 of ...includes/database/database.inc).

Reading over at db_add_field the documentation about $spec mentions 'initial'. Setting that removes the error when running update.php.

New patch attached.

Thanks Michael Lopez! A few things that need to be considered:

- This code should probably be moved from webform_client_form_submit() to webform_submission_send_mail().
- We should make sure this functionality works acceptably when visiting viewing a submission and then using the "Resend e-mails" link. I'm not sure if all e-mails should show up (and be checked) by default, or if they should match the conditional rules by default. If we need to set the default conditional e-mails in multiple places, making that logic into its own function would be a good idea.
- The serializing/unserializing of the conditional_data should be done in hook_node_load() and in hook_node_insert/update, not at the last minute before the data is needed.
- I'd also be okay with just calling the new column "data" instead of "conditional_data", so we can start putting data that does not require a dedicated column in there.

Edit: Fixing typo for clarity.

Might be worth mentioning that the module in #27 was built for Drupal 6.x ... nothing immediately jumps out at me as not being present in D7, but it might be worth someone more familiar with the code changes giving it a once-over.

subscribe

@quicksketch
Great feedback, I will try to start implementing them tonight if I get the time. If not, it will have to wait until the end of the week. I will post a new patch when I have it.

@kingandy
Yes I noticed it was D6. I didn't see anything D6 specific but I will keep an eye out for it.

Thanks

subscribe

subscribe

Ok, quick summary of the patch (it's against master branch):

• Introduced _webform_submission_email_condition_check
• Renamed column conditional_data to data and it is unserialized in webform_node_load
• Re-send checkbox is checked based on submission data for the condition

Noteworthy:
I'm not satisfied with the re-send table in this approach. I'm not that good when it comes to designing UI but maybe it gets somebody else thinking. Because this approach will not work if/when we move this to multiple conditions.

I'm not sure about bypass_condition in webform_submission_resend_submit. But I couldn't think of a better way right now to solve it as I wanted to get this out tonight for more feedback.

Hopefully I'm on the right track. I'd appreciate any feedback as soon as possible as I might be able to squeeze in a few more hours on this issue this week.

Subscribe, the module in #27 is working for me, but I want to see where this issue goes.

I'm on Drupal 7 . Does anyone have a solutions that works for latest version.

Here is the patch from #42 applied to webform 7.x-3.13.
I fixed two minor bugs and added the option to disable the condition and added the conditional status to the email overview table (with a simple enabled, disabled). We could enhance the status with the name of the component it checks against.

For those of us who are still using D6, here is patch #45 backported. I've added some things I thought would sweeten thing a bit more. Here are the details in case you want to put them into the D7 patch and roll it up:

• The Conditional rules fieldset is now displayed collapsed only when it's a new email or if the condition is disabled.
• I added theme('webform_email_condition') and by default it displays the following:
  

  <div class="disabled">Disabled</div>
  

  OR

  <div class="enabled">Enabled</div><div class="component">$cname</div>
  

  Where $cname is the condition's component name.

• Removed the added if condition from _webform_submission_email_condition_check() and expanded the one from #42 to handle the disabled case.
• Set #default_value of conditional_operator form element to '='.

I tested #46 on a Drupal 6 site and it works like a charm. Thanks for that work! I should add that I did run it through the coder module. Coder alerted me about lots of things with the webform module itself, but nothing about this patch.

just wondering when the code will be committed to webform 6.x and 7.x.... or will it stay as a patch only?

@quicksketch ?

just wondering when the code will be committed to webform 6.x and 7.x.... or will it stay as a patch only?

Yes it'll be added to the project when I get a chance to review it again. I think the current patch still needs a bit more work. I'd prefer to have a single function to retrieve the conditional form since we now have the exact same interface in two different places (which I would like to improve upon eventually).

Even though I haven't had a chance to review the code in-depth, I'm assuming that the current approach works, but it'll still need cleanup from the code perspective. When it does get committed, it'll be included in both the D6 and D7 3.x branches.

using the patch from #45 on 7.x-3.13

getting this error when I add a new email:
Undefined index: data in webform_email_edit_form() (line 326 of /sites/all/modules/webform/includes/webform.emails.inc).

Also, the conditional rules do not save after updating the email settings. No matter what field i select or value I put in, the rules are always:

Component: disabled
Operator: is one of
Values: a

getting this error when I add a new email:
Undefined index: data in webform_email_edit_form() (line 326 of /sites/all/modules/webform/includes/webform.emails.inc).

Also, the conditional rules do not save after updating the email settings

You need to update the database after installing this patch as it uses an additional data column to store its information, eg. drush updb

However, since there have been additional ook_update_N() added since this patch was created, it needs to be modified slightly for the latest version. Please see attached for the latest version of this patch, which it based almost entirely on the patch in #46.

This patch works well for me, and I believe it is ready for inclusion in webform. It's useful functionality.

getting this error when I add a new email:
Undefined index: data in webform_email_edit_form() (line 326 of /sites/all/modules/webform/includes/webform.emails.inc).

Updated patch from #51 to suppress this error.
Changed $conditional_data = $email['data']; to $conditional_data = isset($email['data']) ? $email['data'] : array();

When it does get committed, it'll be included in both the D6 and D7 3.x branches.

Now that we've branched for 4.x, this functionality will probably only exist there, as the branching has signaled the end of new features for 3.x. We introduced an entirely new mechanism for conditional logic over in #1215456: Multiple and same-page conditional rules, which contains a reusable widget for conditional functionality. We'll need to revise this patch to use it.

It seems a shame that 3.x will miss out on this feature just because the patch didn't get committed before the branch happened, especially as the patch has been basically unchanged since October last year (the only changes being a hook_update_N change and an error suppression fix). By all accounts, it's patched and ready to go.

@kingandy: Yes sorry about that. There are a lot of feature requests in the issue queue at all times and not all of them make it into the project in a timely manner. The existing conditionals system in 3.x was never very satisfactory and I was loath to expand it to other sections. My original intention with the new conditionals system was to include it in the 3.x branch, but it was too big a change to ensure compatibility with existing 3.x installations. At this point if we start trying to support 3 active branches (6.x-3.x, 7.x-3.x, and 7.x-4.x) even more patches will meet the same fate of death-by-delay.

I need to send to a different email address depending on a selected value. Ideally the value itself would be the email address, but this value comes from a query of the current page and represents a place name, while the email is the owner of the place. So I would rather use a place as query to the form than a long name@domain address.

This last patch should work though if I just clone the email settings and template per email address and use the selected place as an email condition per address. It's not too efficient but works, where without this patch, it would not. So, thanks.

Actually there is already a native Webform way of doing this (and sorry but I could not get the above patch to work)...

• Add a hidden field per email to whom you wish to send.
• Add conditional(s) that "show(s)" (or "hide(s)") hidden email(s) only when value(s) are what you require.
• Add email(s) that send(s) to the value of your hidden email(s). If the email(s) are not "shown," no email is sent.

Wow, very clever Scott M. Sanders! The new conditionals system indeed wipes out values that are hidden (unlike the 3.x branch), so if the fields are hidden due to conditional handling they no longer have a value (so no e-mail is sent).

Thanks for the explanation. This is the functionality I have been looking for :)

@Scott M. Sanders, this will still require the email address exposed in the form html source, correct?

For those still waiting for a final release of the 4.x branch, and still using the patch #52, here's an updated version that suppress warning when using the resend function…

Hey guys, I was reading over http://www.trellon.com/content/blog/webform-bonus-pack-email-routing-web..., whic proposed a clever solution, but it got me thinking that maybe all we need for the vast majority of conditional e-mail handling is a simple mapping.

What if any time you added an e-mail based on a select component, it simply provided a mapping table for each item in the select list. That is if you had a select list with options:

1|Option A
2|Option B
3|Option C

On the e-mail configuration page, if this select list was used as the e-mail source, it would provide textfields for each option:

Enter e-mails for each option:
Option A: [ webmaster@example.com    ]
Option B: [ sales@example.com        ]
Option C: [ support@example.com      ]

This would fix several problems with our system on the whole:
- You could send e-mails to the same address based on multiple options.
- You could easily send to multiple people based on a single option by comma-separating e-mails. (Though see #1160400: Multiple email recipients, one message for caveats)
- Users who have installed Options Element don't need to worry about entering or knowing what keys are used.
- Compared to the current proposal in this issue, it'd be much faster if you had multiple conditional addresses, since you would have to set up a separate e-mail configuration (with a separate template) with the current proposal. This approach would make setting up conditional e-mails for many options a breeze, possibly no slower than the current email@example.com|Option approach, but with none of the down sides.
- We could write an upgrade path to automatically migrate data in the 3.x branch, finally solving #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters).

Here's a screenshot of a patch in progress. Seems like this sort of thing would fit the bill.

#63 looks promising!

Looks great Nate! Will it support a comma separated list of emails so that more than one email can be sent for each option?

I think this sounds like a really solid solution.

Great, glad like it sounds good to you guys so far. :)

Will it support a comma separated list of emails so that more than one email can be sent for each option?

Yes, these new fields (like current fields) should support comma-separated lists. Though sending to all users as a single e-mail (instead of sending individual, separate e-mails) is a TODO task in #1160400: Multiple email recipients, one message.

#63 looks excellent, thanks quicksketch!

Any ETA on a patch for this? I could really use it on something.

(reverting issue title)

Just fixing the issue title after it was changed by the previous commenter.

Has there been any further development on #63?
This would be a great feature to add to Webform!

This looks perfect. Would love to have it implemented. Well done on this solution.

[D'oh]

Sorry, wrong issue, wrong queue, wrong day, more coffee...

@quicksketch: How's the patch coming? I am hoping to use it on a project soon! Thanks.

This patch still doesn't work, but since it's been so long, perhaps someone else can pick it up and finish it faster. I'll still come back to this eventually, but right now I'm swamped with another project.

By "still doesn't work", I mean that the UI is there, but it doesn't save or actually send e-mails based on those settings. Right now this is just the basic API + UI, without saving or actually affecting submissions.

I keep getting fatal: corrupt patch at line 203 with git apply.

hii i am new bee in drupal world, and my boss has assigned me an project to developed an portal in drupal. i have one webform which is for request, as soon as the employee submits the form an e-mail should be send to his manager, manager approve his request and should be able to submit the same form after updating it and this updated form should be mailed to group head. i am struck at this point is there any think plzzzzzz help me...........
i am attaching the image of workflow of the mails as how the same submission will travel from one user to another .

This is a feature I really needed so I went ahead and completed this as best I could (I am a beginner when it comes to Drupal module development).

I have tested it on my test/dev server as well as on my production site and it seems to operate correctly (both running on Drupal 7.22). I haven't done extensive testing, so let me know if anything doesn't work like it should, or if there are any errors in my logic.

This patch includes the mods made by quicksketch's patch on #77, so you shouldn't need to apply both (I have made some slight changes to the content of that patch, so I would recommend applying mine only anyway).

Thanks @skyhawk669!! That's tremendously helpful. The code at a glance looks good. Any reviews of this code would be appreciated. I'd love to include this feature.

This is a great feature!!

Hi,

I tried the patch at #81 and had some issues. At first, I had an undefined index error when creating a new E-mail. Easy fix, had to add some isset() on line 261 in includes/webform.emails.inc.

Good thing is everything works as expected when mapping different emails adress to the values of a select.

But then I had to create another webform which will be sending a "normal" email upon submission. Created the email and tried submitting, but I'd get several errors and the email couldn't be sent. I tried a few settings and realised that the problem came from the email settings form itself.

It seems that in the E-mail header details section of the form, the "Component" options will, by default, use my first field which is a select. (Gender in this case). Upon submit, this default value will be used to fill the extra column in the database with empty mapping values, even if the Custom option is selected as E-mail from address. I believe that the problem must be a missing validation of this Custom option upon submit.. if anyone would be willing to look at it.

Thanks @carolineboivin for the insight. I'm reviewing this patch now and found a few additional issues:

Update.php threw this error at me:

Failed: PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'extra' at row 1: ALTER TABLE {webform_emails} CHANGE `extra` `extra` TEXT NOT NULL; Array ( ) in db_add_field() (line 2841 of /Users/nate/Sites/drupal7/includes/database/database.inc).

This happens when you try to set a field to have NOT NULL = TRUE, but don't specify default values for the field. Schema API has a not-very-well-documented property called "initial", which will set the value to something when the column is created.

Secondly, if you use checkboxes as the source element for an e-mail address, it should send an e-mail to each of the selected options, not just to the first one. I'm rerolling this patch with adjustments. However, overall it looks great.

Here we are. Revised patch that fixes the issues in #85 and #86 and some minor code style changes.

@carolineboivin, @skyhawk669, or others: Could you try this out and see if there are any remaining problems? I'd love to finally knock off this long-standing request. The issue at #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters) has been open for over 5 years. :P

Patches for #87.

@quicksketch, I tried it on my test server and everything seems to work fine. No errors that I can see. Hopefully @carolineboivin can confirm her errors are gone.

Great, thanks @skyhawk669! I've committed the patch in #88. Let me know if you find any new issues.

i patched the module and get this error msg:
Notice: Undefined index: extra in webform_node_load() (Zeile 1345 von /Applications/MAMP/htdocs/manner/sites/all/modules/webform/webform.module).
any quick fix for this problem?

i patched the module and get this error msg:

You don't need to patch the module, this is in the 4.x branch already. I wouldn't recommend applying the patch to the 3.x version, it'll cause you upgrade problems later. Please don't reopen closed feature requests as bugs.

This looks like as very handy feature - thanks everyone for the effort.

I'm unsure how to use this. I want to add a checkbox to my form that says "Send me a copy". I tried adding an email address (node/123/webform/emails/ and then click Add) and then on node/123/webform/emails/new/?option=component&email=2 I see no option similar to "Use only if set component/send always" as described in the original post.

I've looked all through the Components, E-mails, Form Settings (including advanced settings) , and I have ready this entire thread several times over. I am obviously missing something that the rest of you are seeing! A little documentation help, please ;)

This issue is for webform 4.x, so if you are using 3.x you won't have it.

@plethoradesign: According to #2332241: Conditional email sending, the 7.x-4.x version of this is to create a hidden field containing the email address you want to send to, use the normal Conditional system to set the hidden field's "visibility", and set your email to send to the value of the hidden field. So in your case you would set the hidden field to be "visible" (ie, part of the form, though still not shown to the user) when the checkbox is checked. The email should only send when the field used as its "TO" address is present in the form.

I feel like this is a massive fudge, and would much rather see the conditional rules on the email address, but there you go.

Thanks @kingandy. That makes more sense. I do think it would ideally be handled using rules instead of hidden form fields, but it's better than not having conditional email functionality. I'll try it again. I think I had tried the 4.x branch when I commented before, but I could be wrong.

This may be way out of line - but is it feasible that the email address field in the 'component email options' could accept a 'token'?

Only reason I ask it is seemed a very simple way to let a submittor select 'yes' on the form and get a copy of the submission. I.e the webform email would run off a 'select field' (email_me) where I would chose 'yes' to 'Send yourself a copy?' - and the 'email address would be eg [submission:values:email_me]

Perhaps there is another 'easy' way of doing the above but most 'how to' instructions I have seen rely on coding, using Rules etc. Feels like it should be do-able just via webform UI - and the above seemed like a possibility till I confirmed tokens wouldn't be accepted in the field

The best instructions I found to do the "Send a copy to me" is here: https://www.drupal.org/node/1760332#token-email but I get the same thing as petendnz, it's not really a solution but a workaround that doesn't really work in my case. It's probably easier to build a form yourself rather than using webforms and rules and other modules.

I want to send different emails to the same addresses based on conditions in a radiobox list--

If "Subscribe" it would send a subscribe email to the listserv at my company and a Welcome email to the submitter.

If "Unsubscribe" it would send an unsubscribe (delete) email to the listserve at my company and a "You have been unsubscribed to the submitter.

To me, the original idea of having conditionals exposed on the email tab would handle this, but I don't think the current solution (Option A, B, C) would.

Any suggestions?

For the (unfortunate) few stuck on 7.x-3.x: Here's a re-roll of #52 against the latest 7.x-3.x

Correct version of #101