Bug #85301

EXT:form - show hidden fields in notification mail (finisher)

Added by Martin Kutschker over 1 year ago. Updated 6 months ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2018-06-18
Due date:
% Done:

0%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:
Remote Sprint

Description

As side effect of a fix for #81770 notification mails do not conatain the values of hidden fields any more. As editors use hidden fields aong others things to send additional information not provided by the user, I see this as a regression since 8.7.14.

For a customer I had to find a workaround as this change broke many existing forms.


Related issues

Related to TYPO3 Core - Bug #87615: Variants don't use the finisherIdentifier for condition evaluation Closed 2019-02-01

History

#2 Updated by Bjoern Jacob over 1 year ago

  • Status changed from New to Needs Feedback
  • Assignee set to Martin Kutschker
  • Is Regression set to No

This is not a regression. Hidden fields should not be displayed within an email or on a confirmation page. We will not change the behaviour of this in v8. In v9 we will have a mighty system to define (display) conditions. If you are okay with it, I will close this issue.

#3 Updated by Martin Kutschker over 1 year ago

It is a regression as it worked as intended for our customers. It is not up to you to decide if a hidden variable should be sent with the email.

#4 Updated by Martin Kutschker over 1 year ago

I found out about renderingOptions._isHiddenFormElement. But it means that the integrator has to change any form created by an administrator manually.

#5 Updated by Ralf Zimmermann over 1 year ago

If you set this within the form setup, it rules for all forms.

#6 Updated by Martin Kutschker over 1 year ago

I'm sorry, I had a rather bad day until now (I defeated an unwilling VPN client program). Back to normal mode now.

When I wrote notifciation mail I didn't mean the one sent to the frontend user (form sender), but the one to the site owner (form receiver). That's why I wrote that an editor who sets up a hidden field, expects it's value to be set back to him.

For my customer this was a breaking issue as he has lost vital information about the forms content (the products name/id the customer was inquiring). We have been called in to do a hotfix. So even if you think that it is the right behaviour, the changelog of TYPO3 should have had a waning about a breaking change.

I didn't investigate the issue completely, but I noticed that read-only fields are also exempt from rendering. This makes me wonder wether the same class is used for rendering in different contexts. They being "form sender" and "form receiver". IMHO all fields should be rendered in the latter context.

#7 Updated by Webtech AG 9 months ago

  • Priority changed from Should have to Must have

Last week I made a TYPO3 Security Bugfix to V8.7.22 on a website with application forms for job-seeking. I run in this problem too!
The application form has two hidden fields with data which only is visible from the email recipient.

I think such hidden fields are very useful to provide data in the form, which the website visitor can't see but which are essential (!) when transmitting the form data to the recipient. For what else are hidden fields usefully?
I agree that it does not have to be shown on the confirmation page.

#8 Updated by Ralf Zimmermann 9 months ago

  • Assignee deleted (Martin Kutschker)

Since TYPO3v9.4, you can define the visibility of a form element through variants.
See https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84133-IntroduceVariants.rst -> "Hide a form element in certain finishers and on the summary step".

#9 Updated by Webtech AG 9 months ago

  • Assignee set to Martin Kutschker

Thank you for your hint. We are on 8.7.22. I'm trying to find out how it works in the FormSetup.yaml file with renderingOptions._isHiddenFormElement. Right now I got this:

TYPO3:
  CMS:
    Form:
      persistenceManager:
        allowedExtensionPaths:
          10: EXT:wtsitepackage8/Resources/Private/Forms/
        allowSaveToExtensionPaths: true
        allowDeleteFromExtensionPaths: true
      prototypes:
        standard:
          formElementsDefinition: 
            Hidden:
              renderingOptions:
                _isHiddenFormElement: false

It doesn't work. Do I miss something? Is it only for V9?

#10 Updated by Jarvis H 9 months ago

I had the same issue, trying to display a hidden field in a confirmation mail. I believe this is currently not possible to solve because a hidden field has a BaseSetup yaml setting saying that it should not be rendered in confirmation mails.

This variant can not be overridden, so even if you add your own variant with "renderingOptions->enabled->true" based on a finisher condition it will not work.

Here is the base setup of the form extension for the hidden field type:

            Hidden:
              __inheritances:
                10: 'TYPO3.CMS.Form.mixins.formElementMixins.FormElementMixin'
              variants:
                -
                  identifier: hide-1
                  renderingOptions:
                    enabled: false
                  condition: 'stepType == "SummaryPage" || finisherIdentifier in ["EmailToSender", "EmailToReceiver"]'

A non-working attempt at overriding it in a form yaml file would look like this:

-
        type: Hidden
        identifier: someIdentifier
        defaultValue: ''
        variants:
          -
            identifier: in-email
            renderingOptions:
              enabled: true
            condition: 'finisherIdentifier in ["EmailToReceiver"]'

My solution was to create a new custom hidden field in my base setup file like this (you need the HiddenCustom.html partial as well):

            HiddenCustom:
              __inheritances:
                10: 'TYPO3.CMS.Form.mixins.formElementMixins.FormElementMixin'

and now using type "HiddenCustom" instead of type "Hidden" I can render the value in emails.

TL:DR: Variants can't be overridden as far as I can tell.

#11 Updated by Ralf Zimmermann 9 months ago

  • Assignee deleted (Martin Kutschker)

Variants can be overridden.
This custom form setup works with TYPO3 9.5.4

TYPO3:
  CMS:
    Form:
      prototypes:
        standard:
          formElementsDefinition:
            Hidden:
              variants:
                -
                  identifier: hide-1
                  renderingOptions:
                    enabled: false
                  condition: 'stepType == "SummaryPage" || finisherIdentifier in ["EmailToSender"]'
                -
                  identifier: in-email
                  renderingOptions:
                    enabled: true
                  condition: 'finisherIdentifier in ["EmailToReceiver"]'

#12 Updated by Jarvis H 9 months ago

@Ralf I was not able to override it in a form definition yaml file, I see you are testing in the form prototype settings. Are you able to make it work in a form definition file? Besides that your first condition "hide-1" only states "finisherIdentifier in ["EmailToSender"]" and not "EmailToReceiver" so it would make sense that your example works as shown.

#13 Updated by Martin Kutschker 9 months ago

While I understand the reason for #81770 I don't like the way it has been resolved. Nice to see that with variants a workaround may be possible, but it is awkard and not user-friendly. Anyway, this is no solution for v8.

Was there really no other way then to make hidden fields magically disappear by forcing the rendering flag to false? Like using a different property for use in finishers instead of the rendering option (for steps).

#14 Updated by Ralf Zimmermann 9 months ago

@Jarvis please see #87615

#15 Updated by Ralf Zimmermann 9 months ago

  • Related to Bug #87615: Variants don't use the finisherIdentifier for condition evaluation added

#16 Updated by Jarvis H 9 months ago

Ralf Zimmermann wrote:

@Jarvis please see #87615

Ah cool, thanks for taking care of that issue :-)

#17 Updated by Bjoern Jacob 7 months ago

  • Status changed from Needs Feedback to New
  • Sprint Focus set to Remote Sprint

#18 Updated by Ralf Zimmermann 6 months ago

  • Status changed from New to Closed

This is no critical bug and that's why no issue for v8 anymore. With v9 there are "variants" which solves the issue.
Thanks for all the input.

Also available in: Atom PDF