Default/current value not saved in submission when a private field is hidden

Hi there! Thanks for filing this report. I agree that what you've described is happening is not the desirable result. I'm not sure if this is easy to fix, but I think it qualifies as a bug report rather than a feature.

Yes this is definitely a bug. This feature has worked in the past and there is other documentation and comment threads that document using default values and Private fields to inject data, such as statuses, into webform submissions.

Current Behavior:

1. Create new webform field type text.
2. Set default to 2.
3. Make Private and Save
4. Open in new browser window and enter Webform as anonymous user.
5. Default value of 2 does not pass onto Webform results.

Ideal behavior (and how it worked in previous versions:

1. Create new webform field type text.
2. Set default to 2.
3. Make Private and Save
4. Open in new browser window and enter Webform as anonymous user.
5. Default value of 2 passed into webform results.

I can confirm that bug. Fields marked as private won't save the content of "Current value". My use case is a field that fetches it's current value out of a URL's query string. It should not be visible for the person who fills out the form, therefore I marked it as private.

The way this feature was written was that Private components only form part of the submission when they appear on a form. They only appear on a form when the current user has access to Private components. That is why they are blank on submissions from users not authorised to Private components.

The use case you guys describe makes sense, but it did not occur to me at the time of adding the feature.

I don't have the time now to whack together a patch for this, but I think what is needed is an extra loop added to the webform.module function webform_webform_submission_presave($node, &$submission), e.g.:

If current user has no Private component access then loop through all components of the current Webform. If a component is flagged as Private AND is not already present in the submission array AND has a default value set, then inject that component with its default value into the submission array.

Although, re-reading #2 above and retrawling my memory banks, seems there may be a confusion between hidden component versus private component - I don't recall that private components were ever included in submissions from users without private component access.

vernond: What is the difference between hidden component and private component? I can only see the check-button "private". I'm running Webform 4.0-beta1.

@kreatIL: The Hidden component is an HTML component in its own right - that is, you can find it in the dropdown list when you want to add a new component to your form. Such a component is not visible on the rendered form that users see, but you will find it in the HTML source of the rendered page. See http://www.w3schools.com/tags/att_input_type.asp for an example towards the bottom of the page - it is pretty much just a non-visible textfield.

The Private attribute that we added to Webform components was so that we could have components (i.e. any component type) that would only be visible on the form if the current user was an an administrator of some kind.

For example, if you built a form to accept subscriptions then you might want to have a Yes/No dropdown on the form to indicate whether the subscription was paid for or not. Obviously you do not want subscribers marking their subscription as paid if they have not yet paid - so you make it an administrators job to check the bank statements and mark off received monies. So you add the dropdown component to your form and mark it as Private, then only admin users would be able to mark the subscription as paid because only the admin users have access to the Yes/No dropdown.

The Hidden component is mostly used to include information in a submission that the user does not have to fill out themselves.

[EDIT]
It still seems that the title should rather read "Default/current value not saved in submission when a Hidden field is Private" - if that is in fact the case, then the behaviour is expected and by design. A Hidden component is not the same as any component with the Private attribute set. A Hidden component will NOT be part of the submission when the submission is made by a user who does not have the authority level for components with the Private attribute set.

Is there any workaround for this issue? I am using 7.x-3.19 and I have existing hidden fields that I have never marked as private. Now their values are not being submitted if the user goes back in to edit an entry. I've tried granting permission to view all results, edit all results with no luck. I can't find anywhere to set/unset 'Private' on any of these fields. I also don't see how to grant users permission to view Private fields.

Any ideas for a work around would be appreciated.

sandrajihall: My workaround was to make the fields "public" again and to hide them by CSS: display=none;

I still think this is a bug - or at least unexpected behavior: We (tried to) use a private component to inject a custom subject into our webform_emails. Since the component isn't visible, it is not part of the submission thus it can not be replaced in the email.

@vernond: Adding the default value for private fields doesn't destroy the "paid?" use case but makes many others possible.

Here is a patch for a rather different approach: Generate form elements for private fields but with $element['#access'] = FALSE. Checking of $component['extras']['private'] is moved from _webform_client_form_rule_check() to _webform_client_form_add_component(). It also takes care of removing private fields from results.

… and the patch.

… and this time without stray dpm()'s.

Thanks @torotil, I think you're right that using #access in a lot of situations is a better solution. I'd guess that the 4.x version will probably have this problem as well. We'll need to fix it there as well.

This patch looks good, but I don't think this bit is correct:

   if ($format != 'form') {
+    if (!$access) {
+      return;
+    }

This would prevent tokens from working correctly for private components in the 4.x branch, since the renderable is used to render each token. If a user didn't have access to private components, those components wouldn't be included in e-mails (which is already an issue, as reported in #2049785: Private components not available in Webform email).

If instead we use #access on display like we do for the form, this token can be rendered when needed because it'll exist in the renderable. This should have the same net effect as your patch, just using #access instead of skipping the element entirely.

The patch in #15 fixes #2049785: Private components not available in Webform email, so I've marked that issue duplicate.

I've committed these patches to all versions of the module. Thanks @torotil!

Hello, I'm using the latest version of Webform. 7.x-4.0-beta3, but still seeing this issue.

Hi @ncarty97, could you provide a short set of steps to demonstrate the issue? In my testing, this issue has been resolved, but we might be using different workflows that get different results.

Sure.

I have a fairly simple webform, it asks for contact information for a person as an RSVP for an event.

Everything on it is a Textfield or Select options, but E-mail and Phone Number, which I am using the fields created by the relevant modules for those. (I did try recreating the form without those two to make sure it wasn't something in those modules)

All fields are on one page.

When I enable the preview option, the problem beings.

If I click preview from the webform, it does go to the preview page, but if I press previous from that page, it submits the form rather than returning to the webform.

Is that what you need?

Thanks for your help.

If I click preview from the webform, it does go to the preview page, but if I press previous from that page, it submits the form rather than returning to the webform.

This does sound like a bug, but is that at all related to "Private" components? It sounds like this problem should be its own issue, as from your description I can't see how it relates to anything else in this thread.

Needs porting to 8.x-4.x.

Committed and pushed a350821 to 8.x-4.x. Thanks!