Closed (duplicate)
Project:
Webform
Version:
6.x-2.9
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
14 May 2009 at 20:42 UTC
Updated:
11 May 2010 at 10:15 UTC
Jump to comment: Most recent file
This is based off the hashing solution presented in http://drupal.org/node/282436#comment-1068063 . It creates an additional table, and stores a hashed value, as well as the original e-mail in that table. This version is compliant with the new select grouping options.
This patch applies cleanly against 2.6. Patch sponsored by Prometheus Labor Communications.
Robin
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | webform_email_converter.tar_.gz | 1.14 KB | brack11 |
| Email Hashing for Webform - 6.x-2.6 patch | 9.8 KB | robin monks | |
| Email Hashing for Webform - 5.x-2.6 patch | 9.1 KB | robin monks |
Comments
Comment #1
Steve Dondley commented+2 Works well and using this on our sites without incident.
Comment #2
quicksketchThis looks interesting and promising. Does this also fix #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters) if encoding the values?
Comment #3
robin monks commentedNo, hashed emails would still be identical keys; so this would not fix the unique key issue (hence why I split it into a separate issue).
Robin
Comment #4
koyama commented+1 subscribe
Comment #5
m.e. commentedWhere does this patch go, please?
Comment #6
aimutch commentedWas this ever considered for incorporating into the Webform code? Seems like it's a worthwhile addition.
Comment #7
donquixote commentedI would prefer a solution with simple numbers instead of hashing.
Just add a checkbox "use numbers as option keys on client side" to the settings for a multichoice field. We don't need an additional table to store the mapping, it can simply be stored in the form array (not accessible on client side).
Comment #8
quicksketchI'm moving this to the 3.x branch as new features are no longer being added to the 2.x branch. 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.
Comment #9
quicksketchWe'll merge this with #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters) again so I don't have to keep track of 2 issues.
Comment #10
brack11 commentedI decided to not encode emails but rather insert something like "..._at_" at the end because all my recipients are in the same domain. So, I made a little module based on discussions here, and in setup of this module you need to insert mask and domain then use that defined mask everywhere in keys and it will be automatically replaced with domain. Maybe someone would like to try it.