Send emails with a custom/templated body (and subject, to addresses and from addresses)

Improved module help text.

Attachment	Size
webform_mail-beta2.tar_.gz	12.72 KB

Wow. Nice.

I like the approach here. Moving Email settings to another tab both makes it more apparent that there are tabs (I get frequent requests from people that just don't see the tabs at all), and clears up a bit of the normal form.

However, the new page is more confusing than it was before the changes. Some notes:

- New e-mail settings are called "profiles", and yet they only apply to a single Webform? The word "profile" indicates to me it would allow me to reuse the e-mail settings from another webform.
- The e-mail form is already a bit daunting, repeating 2 or more times is even more daunting!
- This approach could render the "Conditional e-mail recipients" obsolete. If you can make multiple e-mails, instead of using conditional recipients, just make another e-mail for each recipient. The "TO" e-mail address would basically need to receive the same treatment as the FROM and SUBJECT to make this work.
- If this were integrated into the module, the "Default" settings probably wouldn't be needed, or they should include the
template area for the e-mail body also.

My bottom line feeling is that this is generally a pretty good enhancement, but we'd need to rework quite a bit of the e-mail system to integrate it properly. With the new ability, some of the current features either don't make sense or are too cumbersome to be repeated in a form several times. This functionality would be much better served as a patch, rather than as a separate module.

(I get frequent requests from people that just don't see the tabs at all)
This might be a theme issue, if the theme doesn't support secondary tabs/local tasks. Though the only time this has happened to me is when developing a theme and removing the line that printed the secondary tabs! So I guess at least most themes support secondary tabs.

- New e-mail settings are called "profiles", and yet they only apply to a single Webform? The word "profile" indicates to me it would allow me to reuse the e-mail settings from another webform.
Yep, they only apply to a single webform (might be nice to have something like in CCK where a previously created fields settings can be applied to another node type). "Profile" was the first word that popped into my head, I'm open to suggestions for another name...

- The e-mail form is already a bit daunting, repeating 2 or more times is even more daunting!
I guess this is the old flexibility vs ease-of-use. Personally I don't find the form daunting, especially with the way the radio options are themed with the option setting next next to the radio selector (nice work on that one!) I don't think it would be a good idea to remove flexibility, but perhaps the form can be simplified using the methods discussed in the next paragraph...

- This approach could render the "Conditional e-mail recipients" obsolete. If you can make multiple e-mails, instead of using conditional recipients, just make another e-mail for each recipient. The "TO" e-mail address would basically need to receive the same treatment as the FROM and SUBJECT to make this work.
I'm not sure that this would work nicely (if I understand you correctly). If the suggestion is to remove the existing conditional email checkboxes, and modify the to address field to have the same options as the from address field, I can see a couple of problems:

• To send the same email to some hard-coded addresses AND some component value addresses would require duplicating profiles (this could be fixed by using checkboxes instead of radios),
• Only one component value could be selected at a time from the select box (unless it was a multi-select box which might not look so good on the form, but perhaps better than having the separate fieldset with checkboxes for conditional component-based to addresses).

- If this were integrated into the module, the "Default" settings probably wouldn't be needed, or they should include the template area for the e-mail body also.
Yes, the default settings form becomes superfluous, I left it there simply to avoid breaking anyone's site. However if this were integrated into webform it would be easy to make an update that copied existing default settings to an email profile (or whatever it gets called) to allow removing the default form without breaking existing settings.

This functionality would be much better served as a patch, rather than as a separate module.
A patch it is! I can probably rework it as a patch once the interface and functionality is finalised.

Will there be an upgrade available for 6.x for this patch, would be sincerely appreciated

This will add the Email Body for the Webform Configuration. This will help in setting the mail body for the webform. You can even use the form components in the body that will replace data filled in the form [ Eg. %title can be added in the body which will be replaced when sending mail.]. I hope this will help alot :).

Please let me know if you have any problems.

Override the .install file and .module file from the .zip in the webform module.

Attachment	Size
webform_patch_for_email_body.zip	26.97 KB

Here's a new version of the original webform_mail module that fixes two bugs (one rather critical, not sure how this slipped by):
5.x-1.1 2009-01-06
- Fixed bug causing only first recipient email address to be used
- Fixed bug where tokens weren't substituted in subject, from name, or from email

In a previous post I said I'd make this module into a patch for webform (instead of a module), but I never did as I just don't have time and the module works as is. Apologies for not doing what I said I'd do! Of course I'd love for it to still be integrated into webform, so if anyone else would like to make it into a patch then go right ahead!

Attachment	Size
webform_mail-5.x-1.1.tar_.gz	12.83 KB

Hi,

This is much needed module and overall looks very good. However, I have a couple of questions/comments:

1. What is the rational behind using the syntax %c[...] for substitutions rather than !.. (which would then make it consistent with the user settings for registration emails) or instead using the Tokens module?

2. Any component type that sets it's values as arrays (i.e., date, time, select) does not get displayed in emails in my testing because the function _webform_mail_filter_body() does not theme the values. Shouldn't the replace[] array be set as in something like:

where we create the required theme functions for each component that requires this treatment?
In the attached I have taken the equivalent theme_webform_mail_xxx() functions from the webform components and included them as webform_response_mail_xxx() in the attached along with the above code. The only difference in the theme functions compared with their originals is that I've removed the adding of labels in the output. If this 'module' and webform where combined then it would probably be better to refactor the original theme_mail_xxx() functions to allow for turning the label on/off to satisfy both needs.

The attached is for Webforms 5.x-2.6.

Any thoughts?

Attachment	Size
webform_mail.zip	14.19 KB

Marking CNW to indicate this issue contains code.

This will be exciting if it finds its way into 6.x! Subscribing.

subscribing. this is a critical piece that we need for this module to do what we need :) thanks for all your hard work!

This is definitely on the docket for the 3.0 version of the module, but it won't be making it into the current releases (or to Drupal 5).

I'm working on implementing this again now that #492806: Separate Webform Configuration from node/edit/x Form is in place. I really can't add this patch as-is because the inconsistencies in handling e-mail doesn't fit with the existing UIs. Instead I'm looking at removing all the e-mail settings entirely from the current location, and place all the e-mail settings in a separate tab with this templating ability.

excellent - thank you very much!

This is much needed. Subscribing.

Alright, well here's the first take at this. I'm pressing forward in an attempt to get to Form Builder functionality and trying to clear out all the blocking/large issues that need to be accounted for first. So I've already committed this patch to the 3.x version (HEAD in CVS). Please update with any problems caused by these changes. For more feature requests expanding on this functionality, PLEASE open a new issue.

Changes:
- New e-mail tab for configuration of e-mails, split off from main webform configuration.
- Death of "Conditional e-mail" configuration, since you can just add a complete webform mailing setting for each component
- Ability to customize the default template (currently there is no ability to save or reuse templates)

Some pics:

Uploaded with plasq's Skitch!

Obligitory warning: This patch will make permanent changes to your database making it impossible to go back to the 2.x version of Webform. The Webform 3.x is not yet suitable for use on a live site.

Attachment	Size
webform_email_templates.patch	67.1 KB

A note on template tokens: I also introduced two tokens for %label[form_key]" and %value[form_key]. This has some drawbacks that Webform does not enforce unique form keys (such as when you clone a fieldset that contains other fields). There's also an existing token for %cid[cid], but I don't like the name of this token and it only gets the value of the field, when really we'd need the label and the value. If anyone has better suggestions for token names, I'm interested. (But let's keep this separate from #428982: Use token.module for token replacement).

Here's another patch to fix some lingering cleanup.

Attachment	Size
webform_email_templates_followup.patch	4.87 KB

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

nice, does this work on drupal6?