[lherlaar]

Hi,

I was wondering about what the limits of validation are in Grocery CRUD. With this I mean the following:

- If a field is an enum it will display as a dropdown in the form, so only valid values can be selected.
- If a field is readonly there will not be an input field generated in the form, so no value can be entered.
- If a field is numerical, only digits can be entered.
- If a field is set as a relation, only valid values from another table can be selected in the form.
- etc.

However, these are user interface (front end) features only, handled by HTML/JavaScript. But what would happen if someone just posts different values for these fields anyway (using firebug or some other tooling, for example)?

My question is: will these checks also be performed automatically by Grocery CRUD on the post data after submission, server side, based on the database field definitions and/or Grocery CRUD parameterization? Or do I have to do these validation checks in code myself?

Of course, I can use set_rules to some extent (such as for numerical fields), but the other checks would require some custom callbacks (such as look-ups in other tables). Furthermore, I could leave some of these checks up to the database (enum, foreign keys), but the error message will then just be a "an error occured" popup.

In other words, do I have to check, on submit whether:

- The value is really contained in the enum values?
- The post data does not contain a value for read only fields?
- The value is really a numerical value?
- The submitted relation field value does actually exist in the look up table?
- etc.

Or can I assume that these cases are being handled by Grocery CRUD automatically?

And as a secondary question: if things are handled automatically, how will this behavior be influenced by using change_field_type? Are the submitted values still checked against the actual database field definitions?

Thanks!