[BC Break][Bug] Form is validating constraints of wrong validation group in 3.1.4 / 3.2

[peterrehm]

#19388 introduces a BC break which just hit me.

I am having an application where FOSUserBundle is used and I have a form manipulating some fields of the custom user entity. Since the above mentioned PR the validator insists on constraints which are not in the same validation group.

E.g. the plainPassword constraint (https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/config/validation.xml#L56) is a problem.

When looking at #19388 it seems after some debugging, that just all constraints of an entity are registered in the defaultValidationGroup which ist just wrong.

     $member->constraintsByGroup[$this->getDefaultGroup()][] = $constraint;

The constraint has the following config extracted from a dump:

NotBlank {#1492 
  +message: "fos_user.password.blank"
  +payload: null
  +"groups": array:3 [
    0 => "Registration"
    1 => "ResetPassword"
    2 => "ChangePassword"
  ]
}

As I see it it must not be registered into the default group which is User in this case.

@senaria can you have a look into that again? I havent had much time to wok around this,
but based on your PR comments I think the adjustment should be mage related to GroupSequence
only?

[yakobe]

I'm not sure I understand your example. Could you add some more information so i can understand your issue?

[xabbuh]

@peterrehm Are you able to provide a test case that used to pass before, but broke with #19388? I would like to look into a solution that wouldn't break @yakobe's fix.

[peterrehm]

@xabbuh Please have a look at #20857 I recommend to revert asap and to look for a new solution. I dont think it will be an easy solution.

[yakobe]

I find it a little dangerous to simply revert the code without a new solution for the group sequence. That would technically create another BC break for people that rely on that functionality. Myself, for example 😁. And also @senaria (the original author of the pr)

[peterrehm]

You two are from the same company, and you broke the validator. That is why imho the revert is needed asap, knowing you dislike it 😃. Then someone should look for a proper workaround. Cant you guys look into this?

[yakobe]

We both have projects that will break if it is reverted. Perhaps many more people do now too? Once something is in a "stable" release, people base solutions on it. It is currenly not so much 'broken' but providing a solution for another use case.

I agree that the current situation is not optimal. I'm swamped right now, but I can take a look as soon as possible. However, before I start implementing a solution i would prefer to reach an agreement about how it should be solved. Otherwise we risk breaking something for someone else, or possibly spending much time developing a solution that would not be accepted. If the repository mainteiners are happy with a proposal then anyone can pick this up... you, me, @senaria, or someone else equally invested in the topic.

[xabbuh]

@peterrehm Can you check if #21183 fixes your issue?

@yakobe Can you confirm that your use case doesn't break with the changes I propose in #21183?