I'm using the [submission:values:foo:nolabel] token on a confirmation page, and found that the value only gets passed if "Access all webform results" permission is granted to anonymous users (it displays fine for admin). The value is included with the actual submission with no trouble.

I may be thinking of it wrong, but it seems as though this should only require permission to access one's own submission? Hopefully I'm not missing anything obvious.

Comments

Status:Active» Closed (works as designed)

My mistake. Because of my limited use-case, I failed to realize that there's no reliable way to identify an anonymous submission with an anonymous user (unless related to the session). It was a long day.

Status:Closed (works as designed)» Needs work

The same problem occurs with registered user.

In this case, the token should be available if they have the "Access own webform results", but it is not. The access to ALL results is needed to have the token available.

Is it easy to fix?

Similar issue here, but in the Subject field.
All fine filling the form with admin account, but when a normal user fills the form a custom element/token is not displayed.
Somehow it works with other fields but I have to investigate a bit more.
The field also does display fine in the email body text - that's strange.

Category:bug» support
Status:Needs work» Active

In this case, the token should be available if they have the "Access own webform results", but it is not. The access to ALL results is needed to have the token available.

Hi guys. There's no need for any permission at all to access any of the tokens. If the token is used and the user is shown the content where that token is used, the submission will be shown there. There is no permission handling around tokens at all. All permissions are checked only when displaying pages that contain submissions. So either the entire page would be displayed or not. Tokens have been supported in the confirmation message since #828566: Webform Token support on confirmation message.

All fine filling the form with admin account, but when a normal user fills the form a custom element/token is not displayed.

What do you mean by a "custom element"? You mean the tokens for Webform fields are not shown?

Yea sorry, I go into some more details now, because I researched a bit and found out some more details about the issue.
Yes I know - I should probably create new issue if this is not about the same thing, just tell me to create a new issue for it if it doesn't fit in here.

Okey, it looks like "normal" tokens do work for me! Also in the subject... (using version 4.0alpha6)
What does not work is the token from a hidden field I have in the webform.
So this is my issue.

When going deep into the complex code (at least for me) I came to the function webform_submission_send_mail in webform.submissions.inc where I found out that the $submission does not have the value of my hidden field in.
I think in this code here, my token gets replaced with nothing:
$email['subject'] = webform_format_email_subject($email['subject'], $node, $submission);
Perhaps this is by purpose (because the field is hidden), but I think that those still should be available for use in tokens, not?
Unfortunately I could not find where this data is created and why my hidden field does not have any value in the token (it displays on the page something you selected in a page before the webform)
Perhaps I should implement this different, but anyway I think the hidden field not in token is some kind of an issue.

I am looking forward to your feedback! Thanks for any help!
PS: What I still have to check is, if this problem gets solved with some more permissions for the anonymous users, as already mentioned in this ticket.

What does not work is the token from a hidden field I have in the webform.

Ahhh, well that could be it then. Hidden fields DO have a special permission set. It's not ideal and I think there is even a TODO in the code there. Users must have the permission to view all submissions for a particular webform in order to see hidden fields, and (apparently) this affects tokens as well. I agree that it doesn't make sense in the context of an individual field token, though it might still make sense for the overall [submission:values] token, which contains the entire submission.

Cool!
But there is no workaround yet I guess...
Do you know where that todo is ? Perhaps I have later some time to investigate again...

Thanks for all your work and giving feedback! Really appreciate that!

The code for hiding hidden fields from "normal" users is in webform_webform_submission_render_alter() in webform.module. It looks like this is supposed to work for e-mails already, but perhaps there is an issue with the handling.

I think this code was just moved in the 4.x branch. @Cyclodex, are you running the 3.x or 4.x version of the module?

I thought its best to go with your 4.x branch
version = "7.x-4.0-alpha6"

Okey, so at least I now know better where to play around to debug that :)

What I also have found when searching for this function was this out-commented one:

  // Meta data that may be useful for modules implementing
  // hook_webform_submission_render_alter().

in webform.submissions.inc

What I also have found when searching for this function was this out-commented one:

Yeah it's not a commented out call to a function, it's a sentence that reads:

Meta data that may be useful for modules implementing hook_webform_submission_render_alter().

The actual hook is called at the bottom of that function.

Version:7.x-4.0-alpha6» 7.x-4.x-dev
Category:support» bug
Status:Active» Needs review
StatusFileSize
new1.25 KB

At some point this got broken I guess. In the function webform_webform_submission_render_alter is something to ignore the foreach loop when the #email variable isn't empty. When I'm sending an email on submission this value is empty. I don't know why and where this happens.

I fixed this by adding an extra variable to the submission object in the webform_submission_send_mail function. I attached the patch. This is working for us so I'm not planning to change the way this patch works. It might be better to fill the #email variable on the right place but for now this patch will do the trick.

I'm having a very similar issue. However I'm redirecting to a custom URL. I followed the instructions from a comment from this post: https://drupal.org/node/1244072

I created two fields one takes a value from the user and the second field is a hidden field that contains the main part of the URL. The issue I'm having is when the user is anonymous and tries to submit the form. The value from the hidden field is not getting passed. I have to grant anonymous users "Access all submissions" in order for the submission to work. The main issue is when these permissions are granted it places a results tab and I really don't want the users having access to that. I guess I can hide it using CSS, but I was hoping there was a better way. Any suggestions or recommendations would be appreciated!

Ouch. I'm trying to add a links to other nodes in the confirmation message, where the node nids have been passed into the initial form page as a url query parameter, then inserted into a hidden field so they persist through the form lifetime. There's no way I want to give anonymous users permission to view any submissions at all.

Ive got a similar problem but very basic sounding problem...

Anonymous user fills in a form. Form includes field such as "name". I've setup some confirmation emails for Webform to fire of, with subject set subject to: Form submission by [submission:values:name:nolabel]

But the token noshows?

I'm new here but this gotta work, hasnt it?

Just in case it helps anyone. I did find a way around the issue. By writing a short module I was able to append the values of both fields and save the appended values into the search field (non-hidden). Because the field is not hidden no permissions were needed to pull the values and redirect the users.

So in short if you save the values into a non-hidden field in the DB, you can call then reference those values via a token and should work just fine.

Status:Needs review» Postponed (maintainer needs more info)

At some point this got broken I guess. In the function webform_webform_submission_render_alter is something to ignore the foreach loop when the #email variable isn't empty. When I'm sending an email on submission this value is empty. I don't know why and where this happens.

Thanks @h3rj4n for this information. I tried to reproduce it as you described but the $renderable['#email'] property was there as it was supposed to be. E-mails came through fine with the hidden values intact for anonymous users (and logged-in administrators) for both plain-text e-mails and HTML e-mails that had been formatted by MIME Mail. I tried putting my token ([submission:values:new_hidden:nolabel]) in the body of the e-mail, the subject of the e-mail, and in the from name. All of them worked properly. So overall I'm still stumped on this one. I can't reproduce the problem at all, so the patch in #11 isn't needed as far as I can tell.

Status:Postponed (maintainer needs more info)» Needs review
StatusFileSize
new1.28 KB

I am back ;)

So I finally had time to get into it, and as you described the issue is the function/hook
webform_webform_submission_render_alter()
I am not sure how to solve it best, so everyone is happy with it, but I leave this decision better to you, as you know the module better...

But here I attached a Patch which is pretty useful for me, what it does:

  • It creates a new permission which describes as "allow access to use "hidden fields"
  • It checks the permission in the mentioned function/hook and does not set #access = FALSE if the user is allowed to see the value.

I made this because I think, we should not decide that a hidden field should just not be displayed (when looking at the submission).
This also fixes the issue that custom tokens are not working, for example when using a hidden field as content of a email subject.

Note: What I want to note: If you use the hidden field as an option in the E-mail subject select field as component, it will show already. But the field is not shown when using the custom: setting for the email subject.

  • That's what this patch fixes now

But please, verify the issue, see why it happens and implement the fix the way it is best for the module...
The patch was made against the last 7.x-4.x-dev state.
Cheers!

Title:[submission:values] token values unavailable to anonymous user without "Access all submissions" permission grantedHidden fields in [submission:values] tokens unavailable to anonymous user without "Access all submissions" permission granted

Updating title, this issue is clearly about hidden fields, not the overall tokens.

I'm not sure about the patch. I think if Webform behaved the way the code comments described, we wouldn't have a problem. The code comments say:

  // If displaying a submission to end-users who are viewing their own
  // submissions (and not through an e-mail), do not show hidden values.

I think that's what everyone is after here isn't it?

This also fixes the issue that custom tokens are not working, for example when using a hidden field as content of a email subject.

I think what you're describing is that adding the permission is allows you to simply disable the check entirely, so then the hidden fields work in the subject of an e-mail. This should work all the time, not based on a permission. I think introducing this would provide a work-around for people experiencing the problem, but it's not actually fixing the root cause. I'm still puzzled as to why I can't reproduce this problem but other people here are having it

I think that's what everyone is after here isn't it?

Can be yes, that was just the way I thought would be correct, but perhaps I should do this differently.
In this case, I want to have a value I need as token for the subject and also to safe in the webform submitted data. But perhaps I will change this a bit, so I don't have to use hidden component for it.

I'm still puzzled as to why I can't reproduce this problem but other people here are having it

I don't get that, you are sure you don't have any webform permission enable and that you are using a normal anonymous user when you submit a form with a hidden field - and this field is then used as custom email subject ?
It all works fine if you have the special permission, or if you are ADMIN user (which you for sure know is always a bit special and has all permissions, even when not selected in permissions overview).

As I have already wrote down, is the issue not the function there, which does make "access" FALSE ?
Even if it now works this way for me, I will try to make a simple D7 install only using webform and check if the issue still exists, so I can verify that not an other module is making us crazy...

Okey, I could really re-produce it very easily...

Took the acquia dev desktop app to create new site, downloaded webform 4.x dev code.
Added a webform node with 2 fields, one normal input, and one hidden field containing some default value.

Use as email subject custom:
[submission:values:hidden_field] -- [submission:values:test_field]

I also put this in the confirmation message:

confirmation message test:
[submission:values:hidden_field] -- [submission:values:test_field]

The output of the confirmation page is finally like this:

Jobs
confirmation message test:
-- Test field: test field value

The email has the hidden field only in the body! The subject looks like this :
-- Test field: test field value

If you really want to see I can also create screenshots or screencast :)

Cheers

Thanks @Cyclodex, so in summary (I think):

- Hidden field token on confirmation page: does not show.
- Hidden field token in e-mail body: does show.
- Hidden field token in e-mail subject: does not show.

In all three cases, the hidden field should be shown. Sound right?

Yes! I think so, I mean you can select if you want to show the value in the body or not.
But when you want to use it in the confirmation page or in the email subject, it should also show up!
(its optional and not must have)

Just to note again: Its only if you use the "Custom" field, if you would select the hidden value in the "component" select-field, it does already show up in the subject!

Heh, okay well now I've tried reproducing the problem on a brand new Webform installation (7.x-4.x checked out from git) and Drupal 7.22 and I *still* can't reproduce the problem. All 3 scenarios work fine for me. I'll the exact situation described by @Cyclodex (using Acquia dev desktop and the dev version). This is simply baffling.

EDIT: Sorry I was logged in at the time. Still testing...

Hey! Yay I finally reproduced it! I got the exact same results as @Cyclodex in #20. w00t! Okay, now to find the problem.

Phew, finally! :) Great!
I was so confused that you could not reproduce it :)

Good luck in fixing it ;) And thanks a lot!

StatusFileSize
new6.06 KB

This patch fixes the problem in my testing. It simply sets #access = TRUE when printing out an individual field's value, no matter what any other modules have set on that renderable. This makes it so that no matter what, if a user says "print this token" by using an individual field's token, it will be printed out.

This fixes all the scenarios above. The general result is this:

  • [submission:values] with "access all webform results" permission always shows hidden fields.
  • [submission:values] without "access all webform results" permission only shows hidden fields if in an e-mail that is configured to include the hidden field.
  • [submission:values:my_hidden_field:nolabel] always works on all hidden fields, regardless of permissions or e-mail configuration.

StatusFileSize
new582 bytes

Sorry wrong patch. This patch fixes the problem but without unnecessary changes. The patch in #26 was an earlier attempt. Please test this one.

Great, works for me!
Thanks a lot for your time and support.
I wish I would have found myself the correct place to fix this!

Status:Needs review» Fixed

Thanks @Cyclodex, @h3rj4n, and everyone who reported on this issue. My apologies I wasn't starting "clean" when testing this problem. I still haven't figured out what was causing the conflict for me, but I'm feeling good that this approach is the "right" thing to do and will solve all the situations with which people are having trouble. Committed to 7.x-4.x. Thanks guys!

Status:Fixed» Closed (fixed)

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