…d forms (webmozart)This PR was merged into the 2.5-dev branch.Discussion----------[Form] Disabled validation/violation mapping of unsubmitted forms| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#9998| License       | MIT| Doc PR        | -This PR fixes submissions of PATCH form in the case that any of the non-submitted forms causes an error (such as not-null).Commits-------9dfebd5 [Form] Disabled violation mapping of unsubmitted forms

This takes into account the changes to the `getErrors()` in Symfony 2.5(the method rturns a `FormErrorIterator` instead of an array) as well asthe fact that non-submitted forms do not accept errors sincesymfony#10567anymore.

This PR was merged into the 2.7 branch.Discussion----------[Form] fix violation mapper tests| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#17099| License       | MIT| Doc PR        |This takes into account the changes to the `getErrors()` in Symfony 2.5(the method rturns a `FormErrorIterator` instead of an array) as well asthe fact that non-submitted forms do not accept errors since#10567anymore.Commits-------f87558d [Form] fix violation mapper tests

…ted (egeloen)This PR was merged into the 2.7 branch.Discussion----------[Form] Consider a violation even if the form is not submitted| Q             | A| ------------- | ---| Branch?       | 2.7| Bug fix?      | yes| New feature?  | no| BC breaks?    | yes (only for the behavior)| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#11493| License       | MIT| Doc PR        |Hey!I'm currently implementing an API using the form component in order to validate the payload sent (in conjonction with the FOSRestBundle). Unfortunatelly, we dig into an issue about the PATCH request which don't map some of our validation rules to the form. Basically, the violations are lost in the middle of the process.### Use caseWe have an entity with the following fields "type", "image" & "video". The field "type"can be either "default", "image" or "video" and then accordingly we use the appropriate field (none for the "default" type, video for the "video" type and image for the "image" type. Then, in our form, we change the validation groups according to our entity type in order to make the "image" field mandatory if the type is "image" and the same for the video field if the type is "video".### Current behaviorThe current behavior (since 2.5) seems to not propages a violation to a form if this form is not submitted but in our use case, changing the field "type" via a PATCH request triggers some new validation which should be reported to end user (inform that a field (video or image) is missing in the PATCH request).### Expected behaviorThe current behavior was introduced in#10567 but IMO, this update is a bug as suggested by@webmozart in#11493 (comment) Instead, the form component should still map validation errors to the form even if the field was not submitted. If the initial data is not valid, then your initial data was buggy from the beginning but the form should not accept it and instead of silently ignoring the errors, end users should be informed and fix it.WDYT?Commits-------c483a0f [Form] Consider a violation even if the form is not submitted

When a form field is not embedded as part of a HTTP PATCH requests, itsvalidation constraints configured through the `constraints` option mustnot be evaluated. The fix fromsymfony#10567 achieved this by not mapping theirviolations to the underlying form field. This however also means thatconstraint violations caused by validating the whole underlying dataobject will never cause the form to be invalid. This breaks use caseswhere some constraints may, for example, depend on the value of otherproperties that were changed by the submitted data.

When a form field is not embedded as part of a HTTP PATCH requests, itsvalidation constraints configured through the `constraints` option mustnot be evaluated. The fix fromsymfony#10567 achieved this by not mapping theirviolations to the underlying form field. This however also means thatconstraint violations caused by validating the whole underlying dataobject will never cause the form to be invalid. This breaks use caseswhere some constraints may, for example, depend on the value of otherproperties that were changed by the submitted data.

…requests (xabbuh)This PR was merged into the 3.4 branch.Discussion----------[Form] do not validate non-submitted form fields in PATCH requests| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#11493,#19788,#20805,#24453,#30011| License       | MIT| Doc PR        |When a form field is not embedded as part of a HTTP PATCH requests, itsvalidation constraints configured through the `constraints` option mustnot be evaluated. The fix from#10567 achieved this by not mapping theirviolations to the underlying form field. This however also means thatconstraint violations caused by validating the whole underlying dataobject will never cause the form to be invalid. This breaks use caseswhere some constraints may, for example, depend on the value of otherproperties that were changed by the submitted data.Commits-------a60d802 do not validate non-submitted form fields in PATCH requests