Seems like duplicate of #3622

Not really, the issue #3622 is about using groups inside the Valid constraint, in my case I don't use groups in the Valid constraint because they are not even allowed. I use groups in other constraints defined in the entities associated with a valid-constrained field.

@guillaumesmo Can you provide your bundle on github?

Here you go : https://github.com/guillaumesmo/src

You have to bypass the HTML5 constraint to test the validation or use a constraint which will not be validated by HTML5

@guillaumesmo It seems like Assert\Valid() is not cascading the validation group. If you add the validation_groups setting you have in CategoryType also into TaskType it works as expected. I guess I had the same issue once and I was just using cascade_validation instead of Assert\Valid. Actually therefore I have never used Assert\Valid().

However it seems like an issue with the Valid constraint. I am unsure if this is wanted behavior. It is also quite strange that at least the validation_groups option on the child form is called. @bschussek can you say quickly anything regarding this behavior? In any case it seems that cascade_validation behaves not exactly the same as Assert/Valid().

In my opinion it's quite clear from the documentation that the purpose of Assert/valid() is to validate the underlying entity.

The only reason I can imagine this being "expected behavior" is if the validation group could only be set from the main form. But in that case we shouldn't be allowed to set validation groups like we did in the embedded form type.

Meanwhile you can use cascade_validation. I was debugging a bit more right now, but could not yet find the root cause. I would like to await some feedback from @bschussek and then we can see further.

Validator should stop any further validation whe it meets Assert/Valid.
Assert/Valid is not accepting any groups so it should be applied for any group.

but currently it ignores Assert/Valid when validation is done for group validationgroup

No I'm sorry but your first sentence is wrong. Citation from http://symfony.com/doc/current/reference/constraints/Valid.html: "This constraint is used to enable validation on objects"

It is indeed not accepting any groups but as I said before I didn't apply any group to the Valid constraint in my example. And your third phrase is a good summary of the issue.

@li0n12 Thanks for the work, but unfortunately you can close your PR, I have the test case already on my machine, unfortunately I could not get into discussion with @bschussek later today, but I hope to be able to get a hold of him next week.

Once I have more information I will get back to this issue.

This doesn't seem to be an easy pick issue, can someone please remove the label?

@webmozart can you give your opinion on this one?

I have just checked it again with 2.5.x-dev and it is also still not working with the 2.5 validator api.
The issue can be reproduced with my branch https://github.com/peterrehm/symfony-standard/tree/valid-constraint. @webmozart Do you still have that one on your Todo list? :)

@peterrehm In my case, when I renamed @Asset\Valid() to @Assert\Valid it worked. You may want to upgrade your demo and test it.

@loostro Just retried it. If I remove the cascade_validation option on TaskType the Assert\Valid does not have any impact. You can try it out with my branch https://github.com/peterrehm/symfony-standard/tree/valid-constraint

@peterrehm @guillaumesmo indeed your efforts to reproduce the issue confirm this is a bug. Thanks!

I did a bit more digging. Validation on a child form is not triggered if the validation groups are only defined on a child form. Defining validation groups on the parent form, triggers child validation.

@jakzal Have you found out why Assert\Valid() is behaving other then cascase_validation? Because iirc it should behave exactly the same.

@peterrehm not yet, it was too late yesterday ;)

// The Valid constraint, on the other hand, is always executed and propagates
// the group to the cascaded object. The propagated group depends on
//
//  * Whether a group sequence is currently being executed. Then the default
//    group is propagated.
//
//  * Otherwise the validated group is propagated.

The way I read it in relation to forms is that if your parent form doesn't have any validation groups, the default one is propagated down.

I would read it the same way. This means it is actually not really a bug just a strange behaviour since
Assert\Valid() works different to cascade_validation.

If you add (in my reproducible branch) the validation group to the main form and not the sub form it works as expected but it is strange.

I think if cascade_validation uses the validation_groups setting of the child form the Validate() constraint should have exactly the same behavior. Especially since we educate that both options are working the same way and are replaceable:

http://symfony.com/doc/current/reference/forms/types/form.html#cascade-validation

ping @webmozart :)

I managed to make it work by passing the cascade_validation and validation_groups as an options to collection field. It works even if i turn off Valid assert.

Be aware with #12237 the cacade_validation option might get deprecated.

@peterrehm I just looked at your demo bundle. You did not set the "validationgroup" on TaskType. If you set the group there and remove the "cascade_validation" settings, then the Length constraint in Category should be validated.

@peterrehm I checked out the demo bundle now and tested it. The validation works for me without doing any changes. Additionally, if removing "cascade_validation" and moving the "validation_groups" option from CategoryType to TaskType, validation works too.

Maybe the crucial point is that the "validation_groups" setting is only respected on the root form (unless "cascade_validation" is used), because that's the form which triggers the validation process.

Yes this is the crucial point. I think it makes no sense to ignore the child validation_groups settings. I think you need to have your validation group logic separated to each form. You don't want to duplicate the logic.

Maybe the crucial point is that the "validation_groups" setting is only respected on the root form (unless "cascade_validation" is used), because that's the form which triggers the validation process.

I think this needs to be in the documentation for Forms. If I'm reading this correctly, then setting validation_groups on embedded forms have no effect, and only the validation_groups on parent form's matter?

It seems counter-intuitive to me that I'd have to set a validation group on the parent form when it only applies to the underlying object for an embedded form.

I'm having this same issue and nothing I'm trying short of manually handling the validation/error throwing is working.

I have an entity, a form type for that entity, and using validation_groups.

The entity has an array property that is associated with second form type embedded in the parent/entity's form type.

The embedded form type have constraints defined in it's properties' options.

I've tried cascade_validation in the parent form type for the array property. I've tried defining a Valid() constraint on the property in the entity's loadValidatorMetadata() class. But nothing seems to trigger the embedded form type constraints.

Does Valid() with validation_groups only work with objects/entities and not property/nested arrays?

If I remove the validation group, all the constraints are appropriately honored (but in this case, I need to use groups).

Validation messages are displayed at the parent form level. I'd like those messages to be displayed at formChild.field level. I'm using Symfony 3.2 version.

@cesarluna Please write your comments in english here

@cesarluna I've translated your message into English because, as @peterrehm said, we only accept English comments in this repository. Please, write your future comments in English. Thanks!

Thanks for the translation

So, since cascade_validation has been removed, should we understand that we are no longer able to set validation_group on embedded forms?

Yes the option is removed. See #17302 (comment). Since the validation groups are still propagated to the childs you are still very flexible.

Yes but that means we are no longer able to set different validation groups for each item of a collection, right?
Or by "flexible" you meant we can manage to do it?

@Kwadz All should be possible, see my docs PR symfony/symfony-docs#4348

@peterrehm, thanks but in this link there is nothing related to set different validation groups for each item of a collection. I think you didn't understand what I am talking about.

Are we still able to to set different validation groups for each item of a collection in Symfony 3?

@Kwadz Read this carefully http://symfony.com/doc/current/validation/groups.html. You can apply all constraints on the main entity depending on your design. This is what I do in my apps. Therefore it is required that you understand Default, Classname,... Groups.

Also have a look at #11880

Also this might give you an option with a custom dynamic constraint which I use in one of my apps #16984