Could someone please explain the criteria that was used for adding validate=options to some select lists but not adding it to others

The filter should have been added to all list fields where we use the value from the list a.created in a SQL statement.

IMO the validate options should be added to all list fields to make sure that only the values that exists are saved.

Could someone please explain why it is necessary to have server side validation in this way on a list but not on a radio

Radio values are usually 1/0, are not directly used in SQL queries and based on a quick test does not seam to be affected by this issue anyway.

Could someone please explain the criteria that was used for adding validate=options to some select lists but not adding it to others

The filter should have been added to all list fields where we use the value from the list a.created in a SQL statement.

That's what I guessed

IMO the validate options should be added to all list fields to make sure that only the values that exists are saved.

I agree 100% and that would mean we would not have needed to update a gazillion lines of xml and it could have been just done once in one place

Could someone please explain why it is necessary to have server side validation in this way on a list but not on a radio

Radio values are usually 1/0, are not directly used in SQL queries and based on a quick test does not seam to be affected by this issue anyway.

Without validation of some sort then they can be modified to have any value (including none as @HLeithner kept telling me)

Anything that will be passed into a sql query needs to be validated etc it is not just list fields.

I have raised this before but jsst keeps ignoring it

I have raised this before but jsst keeps ignoring it

Well I can tell that this has not been raised in the time that I'm in JSST.

Without validation of some sort then they can be modified to have any value (including none as @HLeithner kept telling me)

List fields yes i have tried to do this for a radio field and it did not work.

I agree 100% and that would mean we would not have needed to update a gazillion lines of xml and it could have been just done once in one place

As you know this would be a B/C break and an change like that has to be done in the public tracker anyway. But IMO there is nothing against doing this for 4.0. That would mean an default value validate="options" but maybe with some sort of disable option for extension devs?

Adding validation like this could not be a b/c break

issue was raised sometime in august - can be discussed off list

issue was raised sometime in august - can be discussed off list

You know how to contact me and JSST :)

Adding validation like this could not be a b/c break

Well something is not working like it was before. This would also need to be more deeply tested with fields that extend list and also allow any input like the position field etc. Therefore i suggested to change it in 4.0.

Not much point in me contacting JSST again - I did that :(

Well something is not working like it was before.
Think about that for a second.

• The intended behaviour of the list is exactly the same as it would be before. It is only abusive behaviour that would be blocked
• Any change required for security is never limited by b/c

IMO the validate options should be added to all list fields to make sure that only the values that exists are saved.

I agree 100% and that would mean we would not have needed to update a gazillion lines of xml and it could have been just done once in one place

From an in practice perspective, this is correct. BUT, you should not hard couple a FormField to a FormRule, and you should not hard couple any list based field to requiring the options validation rule. A form's overall structure is a totally separate thing from a set of validation constraints for its data (hence the reason any properly mature application or framework has a dedicated validation API), but the Joomla API tries to cater to a lesser skilled level developer and ties together too many responsibilities into a single god object (the Form class itself).

I'm pretty sure I've said this somewhere before, but you realistically have three separate things inside of one <field> definition in an XML schema that are separate APIs:

• The field type itself, which specifies a Joomla\CMS\Form\FormField instance to use and determines how it is rendered
• A filter option, which specifies what filter inside Joomla\Filter\InputFilter (or one of the special cases inside the Joomla\CMS\Form\Form class because that's a thing) to use when reading the data from the request; changing filter options CAN result in B/C issues because of code expecting the data to be in a specific format (i.e. changing a field that previously had no filter to having an integer or boolean filter can cause breakage with code doing strict checks for string values)
• A validate option, which specifies a Joomla\CMS\Form\FormRule instance to use for further validation of the request data (i.e. is the value a proper telephone number, is the value a proper hex color code, is the value an option in this list, does the value correspond with a record in a database table, etc.; sadly, there is no mechanism to apply multiple validation rules to a field); changing validation options CANNOT result in B/C issues because the validation rule applies to how a specific field in a specific form is processed, it does not affect that data's use anywhere else in the application