Bug #70288
closed
Story #69617: FormEngine bugs
Eval int required check allows 0
100%
Description
The current required check for int also allows 0 values to be used which doesn't make any sense because an empty field is stored as 0 in the DB.
Updated by Daniel Goerz about 9 years ago
I gont agree. 0 is an integer and thus it is correctly evaluated with
'eval' => 'int'
If you dont want empty values to be 0 in your database, adjust your ext_tables.sql to allow NULL in that filed. So instead of e.g.
number int(11) DEFAULT '0' NOT NULL,
use
number int(11) DEFAULT NULL,
And your problems should be gone.
Updated by Andreas Allacher about 9 years ago
1.) What I have is not
'eval' => 'int'
but
'eval' => 'int,required'.
Therefore, I not only have the int check but also the required check.
2.) Furthermore, TYPO3 currently stored 0 in INT values if the fields are empty too.
You only store NULL, if you also append 'null' to the eval list.
So 0 and an empty text field ARE both the same value and should be considered empty for 'required' except if NULL is used too.
Though the question is if it makes sense to allow NULL and have a required check at all.
Updated by Benni Mack about 9 years ago
- Category changed from Backend User Interface to FormEngine aka TCEforms
Updated by Morton Jonuschat about 9 years ago
- Target version deleted (
7 LTS)
Wont be tackled for 7 LTS as this would change behavior
Updated by
Updated by Frank Nägler over 8 years ago
- Status changed from New to Needs Feedback
I can't see here a bug. Maybe I don't get it yet.
I have created a test table and added a field with config int,required.
I can save the record only with an integer value, and the result in the the DB looks ok for me.
0 => 0
1 => 1
an empty string can't be set in the BE and the record can't be saved. So imho no bug here.
Updated by Andreas Allacher over 8 years ago
- Empty field: required check says I have to enter value
- Write 0 and save
- After reload the value will again be shown as empty as 0 and empty are basically the same for int (in database).
- Storing empty field without required check but eval int results in 0 being stored
Updated by Christian Kuhn over 8 years ago
- Status changed from Needs Feedback to Closed
I would like to close this issue. There is a workaround for a lot of cases: You could define a "range" => [ lower => 1 ] to force a positive integer greater than 0. This only fails if you want to allow negative integer, too.
Also, the eval fields have a list of issues with 0 / null / empty string handling and every time we changed something in this area something else broke.
At the moment I'm very reluctant on changing this specific behavior, changes are high it will have side effects we currently don't see on existing fields. And suddenly not allowing 0 as valid int would be breaking anyway and very likely can't go into 7.6.
Imho, we should re-think the required definition if we change the 'eval' thing. Frank had a PoC for that a while ago and it relied on the idea that the current 'eval' does two things: evaluation and processing. Those two should be separate and split, so we'll have a tca syntax change here when that is done, and a change like that will give us the opportunity to get those cases right along the way.
Thus: Keep it like it is now, use a workaround if possible and substitute the whole thing (including rendering, js part and dataHandler validation) when someone finds the time to pick it up in a clean way.
Andreas, this could be a great area to improve. If you find some spare time to do so, please contact Frank and me, I think it should be possible to think about some details in a talk of an hour or two as a kickstart.