This issue is a followup to #781786: Missing hidden components in emails when anonymous users submit, which included a work-around to get hidden fields to show up in e-mails but not when viewing the submissions unless it was an administrator. This problem now only shows up when a user that does not have 'edit all webform submissions' or 'access all webform results' permissions submits a webform and the e-mail is sent by MIME Mail.

Comments

subscribing
I need it in custom form (tell-a-friend) in which i have hidden field 'url' with javascript action, which sets the value with actual url of the image

Subscribing.

I have this issue as well. I need a hidden field to be included in the email.

subscribing

face the same problem too, any recent developments?

Version:6.x-3.6» 6.x-3.17
Status:Active» Needs review
StatusFileSize
new8.24 KB

Just ran into this issue with a site I maintain, once MIME HTML emails were enabled. I believe I have a solution to this issue. We are currently testing it ourselves, but I wanted to share it with you.

Following along with the previous issue thread on this, I examined access checks on line 122 in hidden.inc
$element['#access'] = user_access('edit all webform submissions') || user_access('access all webform results');

Looking at the component display level, there doesn't appear to be a way to signify when a component is being displayed in an email. The check for an HTML format works well for doing this except for when the email is also in HTML. I began exploring webform_submission_send_mail() in webform.submissions.inc since it assembles the emails that will be sent out. From there I investigated _webform_filter_values() (line 2709 in webform.module) since it populates the email template with the submission values.

The first thing I noticed in _webform_filter_values() was the last parameter, $allow_anonymous. The description for this parameter is:

Boolean value indicating if all tokens should be replaced for anonymous users, even if they contain sensitive user information such as %session or %ip_address. This is disabled by default to prevent user data from being preserved in the anonymous page cache and should only be used in non-cached situations, such as e-mails.

Looking back at webform_submission_send_mail(), this boolean is set as TRUE when sending an email, which makes sense. The component display is called on line 2751, so I added $allow_anonymous as an additional parameter, then modded _webform_display_hidden() to accept another parameter. Finally I added $allow_anonymous as another condition to grant access.

All this to say, here is an attempt to get my changes into a patch and into your hands to evaluate.

While $allow_anonymous right now is pretty much the same thing as "sending an e-mail", there's no logical reason why those two should be bound to each other. If we're going to add another parameter to the display callbacks, I think it'd be better if it were something more explicit, like a "display_mode" used in node module.

Now that said, I don't think adding another parameter is the right solution here. The display hook shouldn't need to care about where something is being printed out, just the format that it should print it out in. I think we can make the hidden display callback always return a value now, but use our own hook (hook_webform_component_display()) to hide it from non-administrative users. I haven't tried this out, just a possibility.

I agree that this approach is most likely not the right solution here, but I was trying to avoid a huge architecture shift.

StatusFileSize
new2.05 KB

I think this patch should do the job. I tried to use hook_webform_component_display(), but it didn't have enough context about the form to modify the display properly. Our hook_webform_submission_render_alter() works just fine however. Though this approach requires us to loop through all the components to find the hidden fields, it seems like a better trade-off than having hidden fields entirely missing. Feedback/testing appreciated.

Status:Needs review» Fixed

Tested and confirmed this patch works on both D6 and D7. Committed to both branches.

Status:Fixed» Closed (fixed)

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

Could you some help on how to install this patch.

Regards,

John

Could you some help on how to install this patch.

You don't need to apply it. You just need to upgrade to Webform 3.18 or later.