Spin-off from #2002180: Entity forms skip validation of fields that are edited without widgets
Problem/Motivation
- Entity changed validation (=ensure no one edited the entity while editing it) gets ignored by all entity forms but nodes right now. It works for nodes only, because NodeForm takes care of it manually while all the other entity forms aren't.
- Suppose you have 2 fields (A and B) in a given entity type + bundle.
- Suppose field B has a validation constraint that depends on the contents of field A (e.g., field A is "date of foo", field B is "date of bar", and you want a validation constraint on field B that it is later than A).
- Create 2 form displays: one that contains both A and B, and one that contains only A.
- Using the first form, you can create an entity with values for A and B that satisfy all constraints.
- If you now edit with the 2nd form, you can change A to something that makes B's value violate its constraint, but because the form only contains field A, that's the only field that will get validated, so the form will submit and the entity will get saved successfully, despite being invalid according to its full constraints.
Proposed resolution(s)
- On form submit, validate the entire entity rather than only the fields in the form.
- Allow adding entity level constraints for general validation logic that should run for all changes (e.g. entity changed validation): #2429037: Allow adding entity level constraints
- Ensure all constraints are bound to fields (#4.1) only and document that restriction. (requires above task)
- Work over form validation logic to run complete entity validation, ignore violations based on field access by default (make it overridable from the entity form?)
- #2105797: Figure out the best way to do conditional validation
- However, what to do about violations that are reported for fields that aren't on the form? For example, if B reports the violation (since it's the one with the constraint), its violation message might not make sense (and might expose confidential information, such as that such a field exists) to a person who only sees what's on the form.
Remaining tasks
- Define scenarios for the proper behavior of entity validation
- Write tests for the proper behavior of entity validation
- Use these tests to finalize a resolution for this issue (tests will inform implementation approach)
- Write patch to make tests pass
User interface changes
There is the potential for a UI change. If we validate the entire entity and a field that isn't on the form has a violation, we need to inform the user that they need to contact an administrator or something. In other words, we need to tell them that they won't be able to submit the form until all the constraints are passing, including on the fields they don't have access to modify.
Beta phase evaluation
Issue priority | Not critical because core has no examples of this situation, the situation would come up in only a minority of real-world sites, and contrib/custom code can be written to work around it (e.g., add the desired validation logic). Major because it's a data validation bug, so when it comes up, it can be a severe problem. |
---|