You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#11408 (comment) discovered that invalid DBField values are sometimes cast to a valid value before they are validated when submitted from a form. Instead what should happen is the value should not be cast and should instead cause a valid exception to be thrown
In that particular example the casting happening in DBBoolean::saveInto(). In was possible to get into this state by replacing the auto-scaffolded CheckboxField with a TextField instead, allows "this is not a boolean" to be the submitted value instead of 1 or 0.
Note that historically Silverstripe will often gracefully handle bad data rather than throw hard exceptions. This validation work is essentially the opposite way of handling bad data. Because of this, there may be some instances where this is too much of a change and we may need to soft things a little to reduce upgrade pain
Acceptance criteria
Validation exceptions are thrown by DBFields when invalid data is POSTed into a form submission endpoint
Validation errors are not thrown when valid values are entered into formfields (e.g. using a TextField with a DBInt should not result in validation errors saying "value must not be a string")
The text was updated successfully, but these errors were encountered:
#11408 (comment) discovered that invalid DBField values are sometimes cast to a valid value before they are validated when submitted from a form. Instead what should happen is the value should not be cast and should instead cause a valid exception to be thrown
In that particular example the casting happening in DBBoolean::saveInto(). In was possible to get into this state by replacing the auto-scaffolded CheckboxField with a TextField instead, allows "this is not a boolean" to be the submitted value instead of 1 or 0.
Note that historically Silverstripe will often gracefully handle bad data rather than throw hard exceptions. This validation work is essentially the opposite way of handling bad data. Because of this, there may be some instances where this is too much of a change and we may need to soft things a little to reduce upgrade pain
Acceptance criteria
TextField
with aDBInt
should not result in validation errors saying "value must not be a string")The text was updated successfully, but these errors were encountered: