Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters)

I am interested in knowing how to get around this same issue. Have you tried using "+" signs in the email addresses to differentiate between the two. I.E.

j+ane@example.com|Option1

For some reason, I am not able to use the same address on two options either. Only one or the other will show up. I thought about having to resort to this

jane@example.com|Option1 and/or Option3

I just ran into this myself. It makes sense that this is what's happening - the key is being used as a unique way to identify the selected option, so I'm sure somewhere there's a keyed array which is being replaced.

This gets unwieldly in some use cases. I'm currently doing a contact form, and we want to be able to change the addresses to unique ones later as they are created. I'm hesitant to write a patch to change this behaviour, since keys by definition should be unique. It might be that seperating the email addresses from the keys are the best way to go.

--Andrew

I'd hoped the maintainer would have seen this and directed us towards something he'd commit, but perhaps he's luckier than us and on vacation :). But if there are enough people interested in this issue, perhaps we can get something mostly done.

Here are two ways I see to tackle this:

1. If the 'E-mail a submission copy' option is enabled, we can try to detect duplicate email addresses behind the scenes, and make them unique by adding characters which are not valid for email addresses. Then, when we process a webform (mostly in webform_client_form_submit), we strip out those characters when populating $node->webform['additional_emails'][$cid].
2. We add an additional field to fill out to break the email addresses away from the keys. You make it so you have to specify a key for each select, and then use that key in an additional textarea to specify the destination email address. This would require additional effort to upgrade existing installations.

Anyone have any better ideas? If not, post any thoughts about the above, and we can start patching.

--Andrew

@jcjohnson: That will only work if the destination mail server is configured to handle plus/minus address extensions, which many aren't. So it's probably a good solution for you, but not in the general case.

@deviantintegral: In my twisted world, when I'm on vacation I *am* working on Webform. ;) Right now it's more the opposite that I've got a lot of other things going on.

Anyway, I'd be thrilled to include this functionality. I really like the idea of automatically allowing duplicates if the "E-mail a submission copy" box is checked. Every request I've ever had for allowing duplicate keys is because users are trying to solve this exact problem. So it'd solve the problem for 95% of users without adding any complexity to the form.

To make this possible, I'd suggest automatically turning the keys into integers and not displaying the real e-mail keys at all (this also helps protect against spam bots and is the way contact.module works). Then when the form is submitted, the numeric keys are converted back into their e-mail address equivalents (prior to additional submit code and saving in the database).

Here's a patch to address this issue. I realized that there were three requirements: the email addresses must not be sent to the client, they must be able to be unique keys, and they must be able to be predictable so they can be used with custom PHP validation and such across sites. So, email addresses are md5 hashed and stored in the DB, and when they are sent to the client they are made unique with -# if needed, which can be easily distinguished from the hash itself with substr().

There is one possible area which might cause users some pain; A $hash_emails parameter was added to _webform_select_options(). This means anyone doing custom theming of theme_webform_mail_select will probably need to update their code to call with the hash_emails parameter set to true, or just copy the code from this version. I think it's a small price to pay, and can be noted prominently in the release notes.

I haven't done anything to make this work on Drupal 6. I think only the .install file will need changing to fit the schema API. Also, I don't have pgsql right now, so I haven't tested those SQL queries for install / update.

Enjoy!
--Andrew

Here is an updated patch which applies against the latest -dev D5 version. I'd appreciate a review on this so it can eventually be committed. Thanks!

--Andrew

Hi, thanks for the update Andrew.

I was doing some more thinking about approaches to this, realizing that there's a rather simple solution. Could we simply use the value as both key and value in such a situation where duplicate keys are needed? This assumes that the value isn't used twice of course. So the select list would be something like this:

<select>
  <option value="Option 1">Option 1</option>
  <option value="Option 2">Option 2</option>
  <option value="Option 3">Option 3</option>
  <option value="Option 4">Option 4</option>
</select>

Even if the select options were:

example@example.com|Option 1
something@example.com|Option 2
example@example.com|Option 3
something@example.com|Option 4

I think this would work in most situations. I'm not entirely sure how the solution in #8 works, as using an MD5 hash of the e-mail address will always yield the same MD5 and you'd end up with the same problem of duplicate keys, even though they're now encrypted.

I think this would work in most situations. I'm not entirely sure how the solution in #8 works, as using an MD5 hash of the e-mail address will always yield the same MD5 and you'd end up with the same problem of duplicate keys, even though they're now encrypted.

If a hash is used twice, it adds a -[0-9+] to each subsequent one, and then strips that out on submission. Since each hash is always 32 characters long, it makes it really easy to do in _webform_get_hash_email.

Using the value doesn't work in my situation. For example, we currently have one person in charge of two departments:

<Company Department>
example@example.com|Toronto
example2@example.com|Ottawa
<Company Department 2>
example@example.com|Toronto
example3@example.com|Ottawa

So giving up the ability to have duplicate values while getting duplicate keys doesn't really help. Though I am open to ways to make the above patch simpler :)

Thanks,
--Andrew

Hm, I hadn't thought about supporting (the as-of-yet committed) optgroups. Clearly though, a duplicate value without groups would have less of a possible conflict. There wouldn't be a reason to have "Toronto" twice if they weren't in separate groups.

So... with this in mind, would it be acceptable to key based on "Group - Value"? The situation with appending numbers could get nasty if the user later rearranges the form into a different order. A different problem exists if they rename the departments also, but at least it just creates different records, rather than inadvertently switching them in the results.

Sure, that could work. I'd want 291498: Support <optgroup> in selects to be committed first though. What separator would be good to use between the group and the value? We don't want users to shoot themselves like:

<Group1>
a@b.com|Selection
<>
c@d.com|Group1-Selection

just use different capitalizations! it worked for me :)

returns@estToday.com|Return/Exchange Authorization Request
orders@estToday.com|Order/Shipping Status Inquiry
Customerservice@estToday.com|Technical Support
cUstomerservice@estToday.com|Design Question
cuStomerservice@estToday.com|General Question
privacy@estToday.com|Privacy and Safety Question
pr@estToday.com|PR Inquiries
customerservice@estToday.com|Account Questions

and its future-proof too!

Andrew, when you have some free time could you update the patch for the current 5.x stable version? I also need a solution to this problem.

@tonytosta: Good find! Though, you're still theoretically limited based on the length of the email address. As well, it's not really "clean" to actually support that way, though perhaps quicksketch disagrees.

@jmstacey: Have you tried patching with fuzzing? I think it applied cleanly when I wrote it against the latest stable. In Eclipse, you can have it automatically determine if a patch will apply cleanly with fuzzing, but I don't know how to do it without guessing otherwise. If it doesn't apply, I don't mind taking a look, but be warned that it may be difficult for you to manage your site down the line if this patch changes significantly.

I'm going to hack around with this tomorrow to see if I can get something which addresses the previous comments. Re-reading #12, I'm thinking I didn't think it through all the way and may be able to do as quicksketch suggests.

--Andrew

@tonytosta's solution is excellent as a quick workaround. Would like to see the support for non-unique value email in the option field.

tonytosta's solution works but it can cause emails to be sent multiple times to the same person. What if we simply did a little slight of hand? When a multiple select element with email addresses is saved we will create an email lookup table (i.e. serialized array somewhere (webform_component extra?)) with a unique ID number for each email address. These unique IDs will then be put into place of the typical email address

Now, when the form is rendered the original problem should be avoided. When the form is submitted, we'll look up the email address corresponding to each unique ID. At this point we should add a second check to send only a single email to any unique email address. Upon editing the component we'll have to reconvert from IDs to readable email addresses for the user and then on resave rebuild the lookup table.

This is a hack but it may be less intensive than reworking the way multiple select items are added to create an email registry.

Thoughts?

P.S. - I have not looked at the code base so I do not know what this might get us into.

I think this issue needs to be marked as a "bug" because it solves the problem of spam protection. Never ever reveal any emails of any kind!

Has anyone looked at what would it take to upgrade to D6?

I tried to do this a long time ago (april) w/ D6 and got this answer: http://drupal.org/node/422026 .

This solution was ok for the time being but since then have wanted to do this again, and again. So I thought I would check on this. It seems emails are still not protected in D6...

So I give this a big +1 as I do see it as a big spam risk since I know people are using webform for this... but aren't protecting the emails.

I did some more research and from here:

http://drupal.org/node/273806#comment-1279068
and here: http://www.newriversdigital.com/content/content/non-unique-conditional-e...

There is a solution to securing the emails... BUT....

This will work for me, but not for my clients. What if they want to change the email address, they have to have me do it.

Agreed that both parts of this functionality (the multiple select and the harvesting issue) are really critical for D6. It would be really great if this were implemented - sorry I don't have the developer skills to contribute on this.

(Also, newriversdigital seems to be down/gone. Does anyone have an archived copy of Eric's article, mentioned in #20 and in http://drupal.org/node/273806?)

The 3.x branch has a very different way of handling e-mails that might make it much more feasible to implement a contact.module-like approach, where the e-mails are not part of the list of options at all, but instead tied to the e-mail configuration.

My thoughts on this would be the following workflow:

- Set up a webform with a select list. Give the select list whatever keys you want (or none at all).
- Visit the "E-mail" tab of the Webform configuration, add a new e-mail for the select component.
- Under the select component, enter in e-mails for each value of the select list (multiples or duplicates allowed easily here).

I've set this back to active because it's an entirely different approach than the current patch. I closed the previously branched issue #462932: Encode emails in select drop-downs to prevent email harvesting as a duplicate.

To save an idea from the other thread:

What about an option to automatically enumerate options?
Just add a checkbox "use numbers as option keys on client side" to the settings for a multichoice field. Each option will get a unique number - this will hide the actual values on client side. The mapping can be stored in the form array (not accessible on client side).

These two issues may help with this problem:

#687606: Add conditional email sending feature
#712324: Convert Select and Grid Options to New Data Storage

I came across this issue as I was digging for how to protect email addrs in my select box from spambots. I thought a quick hack might be html-entity encoding the emails, but decided that exposing them at all wasn't a good idea, and obfuscation tricks all have a shelf life as bots get smarter. So, thanks to much help from ericduran on IRC, here is what I have working. An integrated solution is optimal, but in the meantime, this can work for folks just looking to protect email addrs:

---------------------------------

No recipient is put into the main field in the webform admin. Place the code below into Additional Processing (in the webform admin under "Webform Advanced Settings"), and match the strings in the switch statement to values in a select box in the form. ["submitted"][1] needs to be the path in the $form_values array (the array generated when the form is submitted) to the select box element's submitted value. You will likely need to start off with a print_r($form_values) in your Additional Processing to see the array and find the right path to your select form (don't get confused by duplicates in other parts of the array - use the one in the same location as ["submitted"][1]).

---------------

switch($form_values["submitted"][1]) { // this is the path to the submitted value from your select box - it will likely be different, like ["submitted"][3] or ["submitted"][5]

	case 'General Contact': // this is the string from the options in the select box that you want to correspond with the first email addr
		$node->webform['additional_emails'][][] = 'contact@example.com'; // stuff in the email address that you want the submission sent to if they select this option
		break;
	
	case 'Technical Support':
		$node->webform['additional_emails'][][] = 'support@example.com';
		break;

}

Re: #22 - This works up to a point. Using the 3.x branch, I can get it to work like a charm when the Value|Key pair contains only one email address, but as soon as I add a second email address, it no longer works.

How do you "see" the output from additional processing for

print_r($form_values)

re: myself (#23):

We could define a new form element for that, "select_private" or so.
Configuration would be the same as a regular select, but keys would be enumerated instead of being sent to the client as plaintext.
After submission the values are translated back to the original keys.

This is not only useful for emails, it can also be for other things.

Maybe this should be a separate module?

In version 2.9 I did it by adding new module called webform_email_converter with one function in it:

function webform_email_converter_mail_alter(&$message) {
	$search = variable_get('needle','_at_');
	$replace = variable_get('domain','@');
	$message['to'] = str_replace($search,$replace,$message['to']);
}

And everything worked with security issue, I would just add something like email_at_domain.com as a key for selection but in version 3 it doesnt work anymore, looks like there is some type of prior validation of keys and email is sent only if key is the valid email address. Have no idea what to do.

:subscribe:

subscribe

Suscribe

Subscrible

Referring to #25, can you or anyone else suggest a way to accomplish the same thing in the 6.x-3.x branch? The Additional Processing field seems to have gone away in the 6.x-3.x branch.

Thanks,
Matt

Hey,

So I ended up finding a solution for my particular situation. I had a webform with a select component on it called 'Category' and wanted the submissions to be sent to different emails based on the selection. Specifying the email in the key portion of the select options was no good for the reasons listed here. What I ended up doing was writing a small module that alters the webform_email_edit_form form to add in a list box for each select component, that allows the user to filter when the email entered in the 'E-mail to address Custom' is sent. The data from these listboxes are saved to a table installed by the module and the table is checked on hook_webform_submission_presave() to alter the data in $node->webform['emails'] and take out any emails that don't meet the conditions.

One caveat is that when the webform_email_edit_form is in 'new' mode, the submit function I add doesn't know what the eid is of the email being saved, so the extra fields only show when the form is in edit mode. What this means is, to see the added fields, create the email and then go back and edit it.

It's working for me in my situation with filtering on a single select component in a webform. However its built to be flexible enough to be able to filter for multiple select components. I'd be interested to see others try it out and test it. Hope it helps someone or at least furthers the discussion of how to get this functionality into webform.

Thanks,
Matt

I should also mention that I'm working with Webform 6.x-3.2. I make no guarantees for other versions.

m4olivei I love you!

I can't tell you how many people have asked for conditional recipients without compromising their email security to bots over the last year. I, for one, have asked at least twice. To me, and to many others out there, it is absolutely ludicrous not to have this as a built in function of webform. Back in the 90's we starting removing email addresses from forms because of bots. To see modules making email addresses vulnerable to bots almost 15 years later is, in my opinion, insane.

Webform is a very powerful and awesome module. It's a shame that this has yet to be implemented as a built in option. As for now your module does just what I want!

Thank you so very much for your work on this! The minor inconvenience that the email has to be saved first is nothing to cry about from my perspective. I have posted about webform conditional recipients in many forums outside of drupal.org. I'll be sure to point them this way in order to try your module!

Thank you again!

tscadfx: Why don't YOU submit a patch to add functionality you've wanted for over a year? This is a community effort, after all. Sorry for being blunt, but the attitude in your post needs to be addressed.

I still think #28 is the best approach, for anyone interested in producing a patch. If I had the time I would do this myself.
Or maybe a new module to define these widgets? Is it acceptable to give webform a new dependency?

Akalata, this is a community effort, and I have helped many people with various things throughout time. Last night I spent time posting on other forums of this fix and gave a more detailed explanation, in some instances, on how to use the module. I for one, don't have the time, or knowledge, to push out a patch to add the functionality described. I have brainstormed on other forums with people and we attempted to come up with a solution for this issue.

Maybe you need to re-read my post. Those are my feelings, and If you read my post you'll see that I compliment webform and m4olivei as well. I absolutely feel that making email addresses vulnerable to harvesters is insane in this day and age. I have not edited my previous post, and will not edit it. I stand by what I said! If you have any problems with the things I've said I would ask you to pm me, as the forum is not the appropriate place.

On that note ...

For those of you wishing to have a more detailed approach to the module supplied by m4olivei ... here goes:

1 - Copy and install the module. No menu is added and there is zero config.
2 - Go to your already made webform page.
3 - Click on E-Mails
4 - Add a new email with a component value of the select box that you wish to use
5 - Save the new email
6 - Edit the newly created email
7 - Change the component value from the select box to custom and enter the email to which you want the webform to be sent to'
8 - You should now see a box that appears below step #7 ... Select the recipient(s) from the list which will trigger the email in step #7.
9 - Continue to configure the rest of the email settings below and save. Repeat for all others.

The trick here is to create the email first with no settings and then edit it. This is a crucial step otherwise you'll be lost wondering where the module supplied by m4olivei is at. He explains the reasoning for this in his post.

Fear not, for I am going to publish a privatechoice module very soon!

Thanks tscadfx, glad it helped someone.

Here we go,
http://drupal.org/project/privatechoice

All that webform needs to do is add a
'#privatechoice' => TRUE
setting to every select, checkboxes and radios element that should not disclose the option keys. Return values should stay the same.

Private Choice Widget does not have to be a hard dependency. If you install the privatechoice module, option keys on #privatechoice elements will be replaced by numbers. If you don't, the #privatechoice property will simply be ignored.

Hi, sorry but i'm noob with PHP, could you let me know where i should put

'#privatechoice' => TRUE

in order to work with this awesome module?

Thanks in advance...

Actually I did not try this with webform yet :)
Implementation depends if you want to patch webform or rather write your own module.

Hack webform:
In the webform module dir, look into components/select.inc
Look for code that looks like

      $element['#type'] = 'radios';
      $element['#type'] = 'checkboxes';
      $element['#type'] = 'select';

or

      array(
         '#type' => 'select',

etc.
Only 'checkboxes' and 'radios' (plural form), not 'checkbox' and 'radio' !!

And there you can add the '#privatechoice' => TRUE, so you get something like

      '#type' => 'select',
      '#privatechoice' => TRUE,

You need to play with it to find out where to put the #privatechoice option, and where not.
The entire thing gets a bit more complex thanks to the select_or_other and options_element modules.
Please report if this works for you.

Write your own module
(to make webform work with privatechoice)

Try with hook_form_alter() ..

Ok, I'll try even if i didn't know PhP :/

thanks anyway

There is another solution at: #966174: Allow "Long" format email addresses in e-mail components

Then your options can be

Option One <jane@example.com>|Option One
Option Two <tom@example.com>|Option Two
Option Three <jane@example.com>|Option Three

EDIT: Updated to wrap in <code> tags.

Here's a very minimal patch for privatechoice integration.
If privatechoice is enabled, this patch will replace all values for select, radios and checkboxes by numbers.
If privatechoice is not enabled, the patch will have no effect at all.

If we want an option to control this behavior, we need a more complex patch.

And here is another patch, where the change is optional.

Use case:
Sometimes you might want to access the original option values with javascript. In this case you don't want them replaced by numbers.

Why is this all for D6 only?
Because privatechoice does only exist for D6 yet.
Should not be too hard to port the change to D7 some day.

Little caveat:
I did not test 'privatechoice' + 'other_option'. No idea if this would work.

Guys, I will only invest more time in the privatechoice module, if I get some feedback here.
Someone already asked me for a D7 release, but yet I have no feedback telling me if it works for anyone except myself.

Please do so ... Even for D6

@donquixote: I think that the most reasonable approach is #687606: Add conditional email sending feature and I won't be adding conditional support for privatechoice.module. It doesn't make any sense from an architectural standpoint to save e-mails in the database when what you're really concerned about is the value the user selected. Say you had these options:

Marketing
Business Development
Site Design

The most logical keys would be something like this:

marketing|Marketing
business|Business Development
design|Site Design

And not:

sue@example.com|Marketing
joe@example.com|Business Development
frank@example.com|Site Design

It makes absolutely no sense to store e-mails in the database. Especially when one day you need to change the e-mail address that receives the result (say sue@example.com gets replaced with jane@example.com), you don't want all of your results (not to mention your CSV downloads) to get screwed up because you changed the element key.

Instead it makes much more sense to configure separate e-mails for each option. Configuring each *e-mail* setting (under node/x/webform/emails) would allow you to configure who the e-mail would be sent to based on a component value. i.e. "send this e-mail ('sue@example.com') if 'department' receives a value of 'marketing'".

@quicksketch,
that other solution is more reasonable indeed. Looking forward to seeing it live.

I've developed a little module that addresses the combined issue of address obfuscation (for spam bots), and the requirement that email addresses be unique. The approach I took is a little different than above:

1. Using the new hook_webform_select_options_info() hook, the module adds a new "pre-built option list" called "Notification Aliases". This list is user customizable, and allows the same address to be entered multiple times (but the aliases / keys must be unique). E.g.:
   Sales Alias|foo@example.com
   Support Alias|bar@example.com
   Media Alias|foo@example.com
2. When converted into an option array for the form, these are converted into MD5 hashes based on the unique alias / key). E.g.:
   ef1dfe9b594f34b97db4b4b082fce422@example.com|Sales Alias
   db464bdff782ffe49a9b0ef15a94f34b9@example.com|Support Alias
   082fce69ba94f24ef1dfe34b974bdb6d@example.com|Media Alias

   These are now obfuscated (so spam bots will not harvest them), are unique to the option label (instead of the email address), and will pass a check to valid_email_address().

3. Using hook_mail_alter(), the hashed value is converted back into the target email address so drupal_mail() can deliver the message.

Its a little convoluted, but seems to work well enough.

I'd really like to help out with this issue, and would be happy to post this module somewhere, or even create a new project for it on drupal.org. However, if these issues will eventually be fixed in Webform.module as per #687606, I don't want to waste resources or add confusion by adding a new module.

Any feedback from @quicksketch or anyone else would be appreciated.

Take care,
Eric

subscribing!

Looking forward to these spam protection features.

@Eric at NRD,

The email ef1dfe9b594f34b97db4b4b082fce422@example.com will still get spam though, and for those domains with catchall email addresses, this would be the same-ish issue.

@quicksketch / myself (#53, #54)
Still, my full support for #687606: Add conditional email sending feature

In the meantime, would it make sense to have privatechoice as a cheap temporary solution? I think it would be much better than anything with md5 and friends.

If this is not an option, I could instead attempt some form_alter stuff in privatechoice, but this would be more difficult than doing it in webform.

Of course, if you say that #687606 is on top of your todo list, then we can forget about temporary fixes.

@that0n3guy - My snarky response is that anyone using a catchall email address is probably pretty used to getting a ton of SPAM. ^_^

In all seriousness however, do you have an opinion on how to deal with this? One idea that comes to mind - so long as we are traveling down the path of kludge, I can see appending some string as a "hostname" to the email alias address. So in the sample above the email would be something like:
ef1dfe9b594f34b97db4b4b082fce422@null.example.com or maybe:
ef1dfe9b594f34b97db4b4b082fce422@mailalias.example.com

It could even be made into a configuration parameter, perhaps (e.g. "Host name to append to email address aliases: null.").

-Eric

Joining thread

Subscribing.

I have a more complex use case, for a contact form, where the list of possible contacts must be dynamically built. Each entry in the list will have a defined 'role' but the address receiving those messages could change at any time, based on other nodes in the system. I'm going to look at the hook_mail_alter() option to convert role-based keys to actual email addresses prior to sending, as that seems (if I understand the proposed solution right) as the least intrusive approach.

Still, if something else comes of this that would do that for me, it'll be good to know for the future.

subscribing

Subscribing

Is anyone working on implementing the outline in #53?
If so I'd consider chipping in on the work for that one.
/Sten

subscribing

subscribing

subscribing

Subscribing

Also wanted to know if anybody has found a good workaround for the d7 version to accomplish this?

Russ

Ok, so i took the module from #35 and ported it to D7, it appears to work, I have to test it on a live site to be sure, but the settings are where they should be, as described in #40.

Thanks to m4olivei for the original module and to tscadfx for the application and use instructions.

I have attached the d7 version in a .zip.

Russ

Fixed version number and added a readme.

Russ

I've created a little module for D6 that is based on Eric @ NRD's approach. It provides a tab called 'Mail aliases' in the Webform tab bar, which allows you to store alias-destination pairs. Before the form e-mail is sent the module intercepts the message and replaces any matching 'alias' email recipients by their corresponding 'destination' value.

The module has been tested successfully with Webform 3.9 but I cannot guarantee it will work on your setup. Feel free to improve the code and add some more functionality (I haven't yet added the option of removing alias/destination pairs!).

I like the proposal from #53. Any update on that? I am using webforms 6.2 and have it setup like this:

jane_001|Department 1
john_001|Deparment 2
jane_002|Department 3

And then use additional php processing to change the keys into proper e-mail addresses (e.g. jane@company.com). However with php processing removed from 6.3, I can't figure out how else to get this form working.

Ok, Here is a working version of the module from #35 for D7. It works, no errors I can find.

Russ

kd8fre, thank you for your help porting this.

tscadfx, no problem, it was myself, the live site for the coder module and some serious help from the IRC folks.

Not sure if i may have accidentally stumbled on a silly solution - but in case it works for anyone else.

Step 1: set up eg
pete@mymail.com|issue1
john@mymail.com|issue2
info@mymail.com|issue3

Step 2: was asked to set pete@ to info@ and had no problem

Setp 3: was then asked to set john@ to info@ and got the msg about them needing to be unique

so was curious about why i hadn't got that at Step 2 when I spotted that in fact i now had info@mymail| for one and the second had a space at end ie info@mymail | - but since the email was being fired out happily I just went with the flow and made the 3 option have 2 spaces ie info@mymail.com | - and that worked fine too.

So now I have

info@mymail.com|issue1
info@mymail.com |issue2
info@mymail.com |issue3

Maybe i am being even more of an eedjut than usual but it seems to work fine.

@ #35 This works great! I've been trying to get something like this for a little while now with not much luck. Thank you for this. Is there any plans to add this as a project page on the site? Just so it's a little easier to find?

Can confirm #35 works for me too, using Webform 6.x-3.11

There's a conditional formatting module/patch in the making over on another thread that does all this quite well.

(Guards against spam, protects DB keys, and is very very flexible.)

http://drupal.org/node/687606#comment-4454712

subscribe

kd8fre: I just tried the D7 version and I'm getting fatal errors pointing to line 83 in the .module file. Am I right in that db_result() was removed from D7 and db_query() has some syntax changes?

jnettik: I apologize, I just realized that that was the incorrect code. I must have grabbed the wrong zip when I attached it. Here is the corrected, working code.

Russ

Hi ladies and gents, I thought I'd just post this quickly in case it is of use to anyone here - I've got a potential solution for anyone trying to send conditional emails based on the choice made in a select box, but without actually including the email address in the source code and without obfuscating anything. This comes with three caveats:
1.) you need two additional contributed modules: Webform Rules (http://drupal.org/project/webform_rules) and Rules (http://drupal.org/project/rules)
2.) You need to enable the core PHP module.
3.) I've only tested this on the 7.x branch and so have no idea if it works on earlier versions

Once you're installed and and enabled these, set up your webform with the desired key|option pairs in the select field. In my situation it's like this:
general|General Inquiries
product|Product Inquiries
support|Support Request

..and so on.
Then head over to rules and create a new rule. The 'webform_rules' module enables us to jump on the submit event of our webform, and so the trigger event to select is, "After a webform has been submitted".

Next add a condition of type "Execute custom PHP code" and do an if() statement against the condition you want to check for, which should be buried in the $data array. For example, to test if the user selected 'General Inquiries' from the drop down you would do the following:

if( $data['name_of_select_field']['value']['0'] == 'general' ) {
  return true;
}

NOTE: you don't need the <?php ... ?>

Finally add an action - in this case it's the System action, 'Send email'. You can then enter as many email addresses as you like, and you can construct a custom email for presentation of your webform data.

The downside of this is that you have to configure a new rule for each select option (unless someone with better knowledge of the Rules module can improve upon this?!) however, there are no emails on the page and the admin email is highly customizable.

I hope this helps someone else!

kd8fre: I'm using that new version and I'm getting the following errors:

Notice: Undefined index: options_source in _webform_select_options() (line 758 of /var/www/html/mysite/sites/all/modules/contrib/webform/components/select.inc).
Notice: Undefined index: items in _webform_select_options() (line 762 of /var/www/html/mysite/sites/all/modules/contrib/webform/components/select.inc).
Notice: Undefined index: aslist in _webform_select_options() (line 762 of /var/www/html/mysite/sites/all/modules/contrib/webform/components/select.inc).

Edit: I've found that the error is being caused by line 79

  $email_component_values = _webform_select_options($form['node']['#value']->webform['components'][$cid]);

The $cid is pulling my email field as well as my select list. The email field doesn't have an 'items' array in the component which is what's causing the error.

jnettik,

I get the same errors as well, but it does not appear to affect anything. They are just notices. If someone knows how to fix them, let me know.

On another subject, I am in the process of putting together a new site, and may try carl.brown's method to see how well it works.

Russ

kd8fre: I was able to get rid of the errors with the following:

  if($form['node']['#value']->webform['components'][$cid]['type'] == 'select') {
    $email_component_values = _webform_select_options($form['node']['#value']->webform['components'][$cid]);
  }

jnettik,

Just to confirm, you changed line 79 of /webform/components/select.inc to what is in your last post?

Russ

I didn't change it. I just wrapped it in an if() that checked to see if the form component was a select list. That worked for the form I was using but now that I'm thinking about it there'll probably need to be something to check for checkboxes and radio buttons too.

@jnettik - Could you give this module (http://drupal.org/node/1251902) a whirl and see if the SELECT-CASE processing option that it provides adequately handles your use-case? Any feedback or queries on the module functionality can be posted in that issue and would be appreciated.

kd8fre: So whenever I try to submit a form with the module enabled, I'm getting a white screen or fatal error for an undefined function db_fetch_object on line 34. db_fetch_object I think was removed in D7.

Jnettik,

Honestly, I am not a coder, I just took the module that someone further up the page had written for D6 and ran it through the Coder module live site and played with it till I got it working. If you think you would be able to fix it, go for it.

kd8fre

Yeah I'm still trying to learn module development in Drupal. I'll see what I can get going I was just wondering if you had a fix before I put a lot of work in it.

So here is an updated version of the D7 version. I tested it and I'm not getting any errors or WSOD and it still seems to be working.

@jnettik Hello. I've installed your module from #92 but I'm not sure how to use it. I have an existing contact form with a select field with four categories depending on which the email gets sent to a different address. But for the life of me I can't find any new settings or tabs in the admin interface after installing the module. I know I'm probably missing something totally basic but I'm a bit new to Drupal so please forgive me.

Thanks,
David

In the email settings under the webform tab, create a new email address and save it. You have to first create one then go in and edit that address before the new settings will show.

@jnettik Thank you so much. The options show up now but for some reason emails are not being sent when the form is submitted :(

@dckirba What version of Drupal and Webform are you using.

Hello friends!
I have a WebForm (D6) there are elements of the Selectbox and TextField...
Selectbox(field_names) - this is - key|label -> telephone|Name

So the question arose, to submit names (eg Label) is understandable as everything is fine, but how to pass value Key? ie what = tel_name ?????
________________________________________________________________________________

 <a class="popups" href="<?php print base_path(); 
 
	?>node/43?title=<?php print $title; 
 
	?>&amp;name=<?php print $node->field_names[0]['view']; 
 
	?>&amp;tel_name=<?php print $node->field_names[0]['view']; -------????????????
 
	?>"><?php print 'Send'; ?></a>

_____________________________________________________________________________________

WebForm filled on the basis of another Node, and I need to pass the name and telephone number of SelectBox in another form. Thank you very much for your help.

SegeyST: you should create a separate thread for this, as it is a completely unrelated issue.

Russ

There's a really simple way to do this:

jane+option1@example.com|Option 1
mary@example.com|Option 2
jane+option3@example.com|Option 3

Of course, not many people know about the + in email addresses thing :)

I just found a long running thread that sounds like they may be moving this kinda functionality into webform.

#687606: Add conditional email sending feature

Not sure is that makes this a duplicate or not though.

Hi @jnettik: Yep that's the way we'll take to fix this problem. I mentioned that issue way back in #22 and #24. I'm leaving this issue open since it's really a "bug", the other one is a feature request (though it would effectively solve this problem).

The "+ thing" dosen't work on all email servers. :(

is this a revised version of the one from #35?

Hi guys, I've proposed a viable solution for this problem over in #687606-62: Add conditional email sending feature, please weigh in your opinions over there. I think it's a much better solution that approaches recommended here for a lot of reasons:

- Users don't need to worry about using key|value pairs at all. Especially useful if they're using Options Element module.
- It completely decouples the e-mail address from the list of options, so the same e-mail can be used multiple times.

---

EDIT: Ha, after rereading this issue it looks like I already made this suggestion back in #22 but a patch was never written that used that approach. :P

I used to have a solution to this problem using hook_mail_alter but it seems that it no longer works.

The solution worked in 6.x-2.10 but since updating to 6.x-3.18 (the site has been put on hold for updates for a while...) that method no longer works.

What I had was an aliases function that I used to map the select field values to the appropriate email address.

Field Values

at_airhockey|Air Hockey
at_arcade|Arcade
at_billiards|Billiard Tables
at_darting|Darting
at_foosball|Foosball Table
at_multigame|Multi Game
at_archery|Archery
...

Alias function:

function _myform_mail_aliases(){
  $aliases = array();
  $aliases['search'][] = 'at_airhockey';
  $aliases['replace'][] = 'cs1@domain.com';
  $aliases['search'][] = 'at_arcade';
  $aliases['replace'][] = 'cs1@domain.com';
  $aliases['search'][] = 'at_billiards';
  $aliases['replace'][] = 'cs1@domain.com';
  $aliases['search'][] = 'at_darting';
  $aliases['replace'][] = 'cs2@domain.com';
  $aliases['search'][] = 'at_foosball';
  $aliases['replace'][] = 'cs2@domain.com';
  $aliases['search'][] = 'at_multigame';
  $aliases['replace'][] = 'cs3@domain.com';
  $aliases['search'][] = 'at_archery';
  $aliases['replace'][] = 'cs4@domain.com';
  ...
  return $aliases;
}

I then used hook_mail_alter() to replace the 'to' field with the appropriate replacement email.

Hook function:

function myform_mail_alter(&$message){
  $aliases = _myform_mail_aliases();
  $message['to'] = str_replace($aliases['search'],$aliases['replace'],$message['to']);
}

And like I said, in the old version it works but now it doesn't. I'm assuming that in one of the updates there is some kind of "error" checking going on when you set a select field as an email address source to make sure the value is an email address. Which would mean that it would be stopped before the mail alter function got called since it wouldn't validate as needing to proceed to that part.

I'm just assuming here, I haven't looked for the code that controls the email system part of the webform submission but it seems likely since the other email gets sent using the email address supplied by the user.

And further evidence also leads me to believe that may be the case as if I use the suggestion in #75 and add incremental spaces at the end of duplicate email addresses and place that option list into the select options it sends the email out. I just think that's a fairly janky way to do it and would rather just replace them via the alias function I've been using for the past few years.

The only other thing I can think of is to add a validator function to the webform to change the value at that time. Haven't attempted this yet. I'm thinking that quicksketch's solution would be preferable to all this extra manipulation of the data being sent through the form.

oh, one other note, when using the "solution" in #75 I'm now adding trim() around the $message['to'] to eliminate the extra spaces before the mail gets sent. Don't think it matters but still, rather do it now than to have it somehow end up causing a problem later.

After a long read of this issue and #687606: Add conditional email sending feature, I am attempting to summarize the potential solutions to allow functional conditional emails (including multiple per option) that are protected from spambots in D7 webform:

1. Webform_select_email module: Latest tarball is in comment #92.
2. Condtional email sending patch to webform 7.x-4.x in comment #61 of #687606: Add conditional email sending feature.
3. @quicksketch's proposal in comment #62 of that same thread. At this time, no patch has been posted for review of that proposal.
5. strange work-around: in #57 of the same thread mentioned above.
4. Webform_bonus (mentioned in blog post which also summarizes using webform_php or writing a custom module) but does not have a release candidate, the 7.x branch hasn't been committed to since sept 11 and there are some bug reports in the queue.

Hopefully soon this can have one solution and this thread can quietly collect dust.

#92 +1 worked for me, Thanks guys!
- just had to re-save the archive so folder name matches .info name and was able to do UI module install no probs.

edit: For D7.22 + Webform 7.x-3.18

#687606: Add conditional email sending feature now has a patch that is nearing final review. Anyone that is interested in solving this problem permanently, please take a look over in that issue and review the patch.

#687606: Add conditional email sending feature has been added to the 4.x version. Unfortunately this means that D6 won't see this feature since 4.x is for D7 only. Anyone that needs the temporary work-around, you can use the module in #81, but it would be preferable if this module were maintained separately as a project (even as a sandbox), instead of being a zip file.

Although this issue is now a duplicate, I'm marking this fixed so it'll show up in people trackers.

...people might get the wrong impression that this was fixed in 6.x. So, either branch change or switch back to 6.x and mark won't fix (as per #109 above).

Thanks @klonos. And to double-reiterate, as with all new changes, this is also only fixed in the D7 4.x branch, which is not yet the recommended release on the project page.

#13 worked for me. Thanks tonytosta.