Add the option for a form to use the submitter username and email address as the from address.

Ooo, interesting. If I understand correctly, this patch make the username and e-mail address the "from address"? I'm not sure where passwords come into play.

This looks like a good approach, but it's worth mentioning that you can do this anyway with two hidden fields with the default values of %username and %usermail, then use those component as the From name and e-mail. Regardless, this might be a nice shortcut. What happens when the user is not logged in?

Yep, I think this would be a good enhancement. If you can tidy up the enhancement and port it to 6 I'd be happy to commit it.

Thanks rmiddle, this code all looks fine to me. Sorry I've been completely swamped trying to get stable versions of FileField and ImageField released. Next time I'm working on Webform patches I'll add this in.

There is one small bug inside a translatable string. t('Use submitter\'s information if anonymous users use default.') need to be changed to t("Use submitter's information if anonymous users use default.")

Well now this has taken so long we're not working on 2.x anymore. Moving to the 3.x queue. Thinking of an alternative, we could just run _webform_filter_values() on the e-mail values, meaning you could just set the e-mail to %useremail and from to %username, then we wouldn't need to add another radio button at all.

I would very much like to see this working when the submitter is not logged in. I use web forms on a public site -- the only "Users" on the site are the admins, so forms are always submitted by people not logged in.

I would like to have an "email" field, and if (!) it is filled in, that is the return address on the email.

(As a side note-- I'm a bit confused. Why do so many Drupal updates linger for so long? This apparently had a working patch for **over a year** ready to be committed, and then "Whups -- too late!" Does Drupal just not have enough committers to go around?)

@strider72: Webform is pretty much maintained just by myself, and I also maintain a dozen other modules and make regular contributions to core. Since I don't actually use Webform on a regular basis, the features that get reviewed and go into Webform are frequently added based on the time I have available. So yes, there is a dearth of reliable committers that are able and willing to contribute their time, especially since it's done in free time and rarely paid for.

Also, still not going into 2.x, this is a 3.x only feature since 2.x is nearly at the end of its rope.

@quicksketch: As a contributor to WordPress (and several plugins for it), I appreciate the nature of free open source coding. ;-)

I guess I'm just surprised that this particular one only has one person maintaining it, as web forms are such a *basic* thing I would think there was a huge demand for this module.

Either way, thanks for plugging away at this (so to speak). Perhaps when I have a better understanding of the Drupal plugin API I'll contribute to this plugin.

To clarify, the current intent is to use Webform's Token system for From: email configuration? I will roll a patch to that effect.

As an aside, is there a reason this does not use the Token module?

Hi Grayside, yes I believe the current direction is my suggestion in #10:

Thinking of an alternative, we could just run _webform_filter_values() on the e-mail values, meaning you could just set the e-mail to %useremail and from to %username, then we wouldn't need to add another radio button at all.

Regarding token.module, see #428982: New hooks for additional token replacements.

Okay.

I see that the email subject is using a %title token by default. This does not appear in theme_webform_token_help(). Does that mean it is not part of the webform token system?

The help is not based on the actual tokens available (though it tries to include all of them). The best thing is to check _webform_filter_values() and see what tokens are available there. %title should be added to the list of tokens in the help.

Looking at this, I see there are global email settings at admin/settings/webform, and also email settings at node/#/webform/emails. However, the settings of the latter do not seem to be pulling global defaults.

What do you want here?

The global settings are just the defaults, they're never used directly they just set the defaults for new e-mails.

Right, but the webform-specific email settings are not pulling the global defaults in as defaults, they are using the same sitename/siteemail used in a vanilla install. So either there is a bug, or I have no idea what the Email From: settings do in the main settings form.

Maybe this screenshot will help.

The improper ordering of subject, from, and email should probably be fixed at some point. :-)

Thanks. So that confirms that what I see looks like a bug. When I save those settings to admin/settings/webform, they are not used as defaults on the specific webform's email configuration.

I will confirm that and create a separate issue as needed.

Okay, what I'm seeing is a UI issue with filtering the tokens to build the email address/etc in building the UI. Back on forward momentum.

webform_format_email_address() in webform.module applies filters the email addresses. This creates confusing UI where the webform administrator sees the processed tokens, such as their own email address. Since there are already so many arguments going into this function, I wanted to ask: is a preference on how to conditionally skip token filtering?

Ah interesting. It sounds like webform_format_email_address() shouldn't be getting called at all then if you're wanting to show the original tokens and not the final e-mail address? If you can make a generic attempt at fixing the problem I'll see if it makes sense, it'd also help me understand the problem fully.

Hm, I never thought about not calling it. I assumed if there were no tokens the rest of that function did desirable things. I think it's important in the node/#/webform/emails page that if the form creator used %useremail, he's not confused by seeing his own email address.

Okay, now accepting tokens for email address configuration.

This did not require touching the actual email submission system, as that already checks for tokens.

Summary of Changes:

1. webform_format_email_address() and webform_format_email_subject() now have a $filter_tokens argument. If false, the _webform_filter_tokens() function is *skipped*.
2. The per-webform email configuration UI now displays the configured email without token filtration, meaning the form administrator can see the tokens. I could not decide if there should be further documentation around the UI explaining this.
3. Custom email address per form puts the user input through the filtration process to double check correct use of tokens. This means the currently logged in user needs to be valid if things like %useremail are to be used. [see webform_email_address_validate()]

subscribing

So I'm reviewing old patches now and finally took another look at this issue. I don't like all the new parameters added by the patch in #27. We've already got 5-7 parameters on these functions and adding more just makes our code more difficult to follow. The overall effect of the patch doesn't seem to make things easier to understand, though it would provide a shortcut for advanced users. Overall I'm not sure there's a net-gain for this patch.

Moving this to needs work pending any feedback. Right now I'm leaning towards won't fixing this issue.

There won't be further feature development in the X.x-3.x branches.