Project

General

Profile

Actions

Bug #70288

closed

Story #69617: FormEngine bugs

Eval int required check allows 0

Added by Andreas Allacher over 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2015-10-02
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #41511: TCA eval int,required does not accept 0 (zero)Closed2012-10-02

Actions
Actions #1

Updated by Daniel Goerz over 8 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.

Actions #2

Updated by Andreas Allacher over 8 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.

Actions #3

Updated by Benni Mack over 8 years ago

  • Category changed from Backend User Interface to FormEngine aka TCEforms
Actions #4

Updated by Morton Jonuschat over 8 years ago

  • Target version deleted (7 LTS)

Wont be tackled for 7 LTS as this would change behavior

Actions #5

Updated by Mathias Schreiber about 8 years ago

  • Parent task set to #69617
Actions #6

Updated by Frank Nägler about 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.

Actions #7

Updated by Andreas Allacher about 8 years ago

Yes, I can save 0 but it doesn't make sense if I use required and the value is not nullable.
  • 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
Actions #8

Updated by Christian Kuhn almost 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.

Actions #9

Updated by Christian Kuhn almost 8 years ago

  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF