Bug #91029
open
Validation fails if nested properties of same type are present
0%
Description
I recently stumbled upon an issue regarding the validation process and after some debugging I was able to track down the problem to be exactly the same problem that has already been fixed years ago in the FLOW framework:
https://forge.typo3.org/issues/50585
Long story short:
The validate() methods in- TYPO3\CMS\Extbase\Validation\Validator\AbstractValidator
- TYPO3\CMS\Extbase\Validation\Validator\CollectionValidator
- TYPO3\CMS\Extbase\Validation\Validator\GenericObjectValidator
will override $this->result every time they are called not preserving previous error results that might eventually already exist.
In the FLOW framework this is being handled by pushing the previous error result on a stack before the isValid() method is being processed and then popped backed out again afterwards.
See here as an example:
https://github.com/neos/flow/blob/master/Classes/Validation/Validator/AbstractValidator.php#L150
It also looks like this problem still exists in TYPO3 10.x as the validators mentioned above still look the same as in TYPO3 9.5
Updated by Alexander Schnitzler almost 5 years ago
Is this possibly the same issue as mentioned here? https://forge.typo3.org/issues/89971
Updated by Georg Ringer almost 5 years ago
- Related to Bug #89971: Extbase validation broken since merge of "58833: [BUGFIX] Keep existing validation errors for recursive domain relations" added
Updated by Bastian Stargazer about 4 years ago
We run into this issue in v10.4.12 ... not 100% sure if it is the same one, but it sounds like it. Was very hard to tackle it down!
The setup is the following: An Order-Entity should be validated with a custom OrderValidator. But it is never called, because the validation loop is exited "too early". The reason might lay in a circular (weak) dependency in our case:
Order => belongs to a User
User => has several Subscriptions
Subscription => might has an Order (if it was booked) or not (if the subscription was manually added through the BE)
So, if the validation starts with the Order object (starting with the GenericObjectValidator first), it goes down the nested properties (Order => User => Subscription => Order(?)) and might validates the empty or not-existing Order object of the Subscription as "valid". Later in the process it seems that the validation-loop is exited before the second validator (custom OrderValidator) has the chance to run.
No exception is thrown, no message is given, because for the GenericObjectValidator everything is valid and the OrderValidator did not run.