Important: Form data transformation only maps submitted fields
Description
The frontend editing of EXT: maps submitted form
data transfer objects (
\FGTCLB\
descendants) onto the domain models through the per-property factory
classes in
\FGTCLB\.
Until now these factories wrote every property on each request, so a field that was not part of the submitted form was silently overwritten with the empty default of the form data object, wiping already persisted data. This is corrected: a property is now only applied when it was actually sent within the current request.
To make this possible the following additions were made (all of them on
@internal
classes that are not part of the public API):
\FGTCLB\carries the current request and the mapped argument name and exposesAcademic Persons Edit\ Domain\ Model\ Dto\ Abstract Form Data wasto detect which properties were part of the submission. The request and argument name are provided by the newProperty Sent In Request (string $property Name): bool \FGTCLB\, which is registered for allAcademic Persons Edit\ Property\ Type Converter\ Abstract Form Data Converter Abstractbased arguments inForm Data \FGTCLB\.Academic Persons Edit\ Controller\ Abstract Action Controller:: initialize Action () - All factory classes (
Profile,Profile,Information Contract,Address,Email,Phone) skip properties that were neither sent within the request nor registered as override. The existingNumber readOnly/disabledvalidation configuration keeps precedence and continues to protect persisted data. - For the case where a property is not part of the request but still has
to be written - for example when a PSR-14 event fills up data from
another source before the transformation runs -
Abstractgained a per-property override store viaForm Data set,Property Override (string $property Name, mixed $value) hasandProperty Override (string $property Name) get. Registered overrides are applied even when the property was not submitted.Property Override (string $property Name)
Additionally
\FGTCLB\
was fixed to evaluate the validation configuration of validTo instead
of validFrom.
Impact
The runtime behaviour of the frontend edit forms changes: submitting a form no longer resets fields that are not contained in that form. Fields are only written when they were part of the request or were explicitly registered as override on the form data object. No public method signature changed in an incompatible way.
Affected Installations
Only installations that extend or replace the internal form data factory
classes or
Abstract, or that relied on the previous
"always overwrite" behaviour of the transformation, need to take the
changed behaviour into account. All other installations benefit from the
fix without any action required.
Migration
No explicit migration is required. Custom code that populates a form data
object outside of the request (e.g. within a PSR-14 event) and expects
the value to be persisted must register it via
Abstract so the transformation
applies it despite the property not being part of the request.