TCA type-field and required fields bypass
I'm using a TCA type-feature, when some table contains so called "type-field",
which defines different views of same record at BE.
Let's see following cases of type-switching:
1. Record is already existing, field is required and it's content was changed
- switching type saves the field and reloads the form;
2. Record is already existing, field is required and it's content was set to empty
- switching type doesn't save the field, reloads the form and restores previous field's value;
3. Record is new, field is required, and it's content is set to something
- switching type saves the record with field's value and reloads the form;
4. Record is new, field is required, but not filled with anything
- switching type saves the record with empty required field.
As you see, we have a problem in item 4, since user can bypass a required field validation, and it may break a logic of application, which requires some fields to be filled with something.
Updated by Mathias Schreiber almost 6 years ago
- Status changed from New to Needs Feedback
- Assignee set to Mathias Schreiber
This is pretty hard to implement (if not impossible).
Reasoning is that you could have two types with different sets of required fields.
But: Would it be sufficient if we denied switching a type field until all mandatory fields have been filled in?
Updated by Viktor Livakivskyi almost 6 years ago
Would it be sufficient if we denied switching a type field until all mandatory fields have been filled in?
It can be applied as a workaround, if there is no way to not store a record, when type switches.
The only downside I see here: user accidentally chose wrong type with lot of required fields. So, to select a correct type, he needs to fill all these fields with some dummy data to be able to switch.
Updated by Jan Kornblum 8 months ago
- TYPO3 Version changed from 4.7 to 10
- PHP Version changed from 5.3 to 7.2
Still a problem, especially when working with single table inhertiance.
+1 for the workaround from matthias schreiber.
Another workaround might be: Highlight (warning) "invalid" records in "weblist" module. So the editors at least can easily identify invalid records.