Instead of removing that option I'd prefer it would be recursively passed properly to all children (as I expected from its name). That would make validation more failsafe when you don't need to remember adding the Valid constraint everywhere. When I validate something, I expect that even data in child forms is validated, so I had to generally set cascade_validation in all my forms, but sometimes got hit by #5204 and had to add an additional Valid constraint to make validation work properly. Thus 👎 from me.

@craue cascade_validation was introduced s a way to reproduce the 2.0 behavior of the form validation. It is not intended to be the standard way of validating forms (which is why it is disabled by default).

Why don't we think about validation by default all child entites? I think this is what you usually need. I acutally got used to cascade_validation since it is the way how it has been documented.

http://symfony.com/doc/current/book/forms.html#embedding-a-single-object

When docs will be updated this should be covered as well.

In addition to that Assert\Valid() works differently compared to cascade_validation as discussed here:

#9650 (comment)

I think the way how cascade_validation works is actually what you would expect. There are cases where your child forms will have validation groups based on there state so you should not add this to the parent form. Or what do you recommend in regard to this?

I would say if this is changed the validation_groups of the child forms should be respected accordingly as with the cascade_validation setting. I would assume moving all people from cascade_validation to Assert\Valid() and not providing a solution for the validation_groups setting to have validation groups based on the entity state would lead to many issues.

Or we add another logic and tie the logic to the entity as we started to discuss here #11880.

@craue As I mentioned in the ticket description, there's almost no valid use case to use "cascade_validation". Use the Valid constraint, always.

@peterrehm This is in fact a documentation issue. I opened a new ticket there: symfony/symfony-docs#4346

Or we add another logic and tie the logic to the entity as we started to discuss here #11880.

That's the correct approach to solve the problem IMO.

Is there anything else affected rather than the validation_groups setting of the form?
How about deprecating the validation_groups setting as well when we find a solution for #11880.
I will try to reply to you later today or tomorrow.

How about deprecating the validation_groups setting as well when we find a solution for #11880.

I'm not sure that's a good idea, but it's an option.

But if not deprecated (I don't know as well if it is a good idea) I think we should consider cascading them as cascade_validation does.

ping @symfony/deciders

The "cascade_validation" option was designed for a 1% use case

@webmozart what is that 1%?

@webmozart this PR should probably be sent again with the 2.7 branch as target (and rebased) so that tests can run (Travis is currently not working on 3.0.x-dev even if you rebase).

I would like to see #11268 fixed as it is a nasty bug.

Any progress on that one?

@Tobion The use case when you have a subform with an object that is not referred to from the parent form's object (so @Valid can't be used). In practice, this rarely happens.

Replaced by #15019.