TASK: Improve export when form definition changes, allow setting node…

[lorenzulrich]

…TypesIgnoredInExport

This package only stores the FormElement identifier at the time of form
submission in its entry data. This has some drawbacks:

• If a field identifier is added or removed later, it breaks the export
• The field identifier could be a uuid which makes it hard to read

This change improves this as follows:

• A unique list of each field identifier of each submission is compiled
• The ContentRepository is used to look up the actual field labels if
  the form still exists.
• There is a fallback to the field identifier if the form or field don't
  exist anymore.

Furthermore, the export contains too much information, such as Sections,
Captchas (if configured) and possibly sensible information such as
Passwords.

A new configuration nodeTypesIgnoredInExport is added to prevent the output
of fields configured. The following types are excluded by default:

• Neos.Form.Builder:Section
• Neos.Form.Builder:StaticText
• Neos.Form.Builder:Password
• Neos.Form.Builder:PasswordWithConfirmation
• Neos.Form.Builder:HiddenField

[lorenzulrich]

Replaces #23 and also resolves #7.

[Benjamin-K]

Thanks for the updated / new PR for this feature. Do you want to add the options discussed in #7 in this PR or do you prefer opening a new one for this afterwards?

[lorenzulrich]

Please do not merge this yet. I have some feedback from testing I'd like to integrate first.

[Benjamin-K]

I will wait for your feedback.
I assigned this issue to you. If you're done, i will assign it back to myself.

[lorenzulrich]

@Benjamin-K I improved this PR again. Do you have an installation with Node-based forms where you could test this yourself? There are many changes and I'd like to be sure if everything works. I also let our customers test it.

[Benjamin-K]

@lorenzulrich Thanks for your improvements. I currently do not have an installation with node based forms that also have the DB-Storage. Your changes look compromising, but i will wait for your feedback before merging. If you say go, i'll merge ;)

[lorenzulrich]

I hope the changes look promising, not compromising ;-). I will give you feedback as soon as this is tested thoroughly.

[Benjamin-K]

Dough, sure. Thats what i wanted to say, sry :D I added two little comments for review and will also test your changes with the node based form.

[lorenzulrich]

I added a last feature to allow excluding certain form element types in the finisher, not storing the value at all. This is an additional feature to hiding them in the export and list view.
I would be best helped by testing this also in instances without Node-based forms. In this case, everything should behave as before. What kind of scenarios do you have @Benjamin-K? YAML-based forms or Fusion-based forms?

[Benjamin-K]

We do not have any yaml based forms any more and only one fusion based form so far. But in this setup the live website only has read access to the database, so i can't test it there. Will see if i find some time to test it, but not within the next two weeks.
Thanks for the additional update, btw.

[Benjamin-K]

@lorenzulrich Have you used your update on some sites? I would like to merge your feature and rather fix bugs later than not having this feature, as we do not have any yaml based forms at all and almost no fusion based form.
We can create a new major version for this so that it is clear that it might be breaking. What do you think?

[lorenzulrich]

@Benjamin-K In the meantime, I could test that it doesn't break any installations with Fusion-based forms. I also had no negative reactions from the usage in Node-based forms. However, I would release it as a major version because it is definitely breaking - in terms of showing different data when fields were renamed/added/removed over time.