Actions
Defect #12955
closedMisbehaviour in estimated time validation
Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Issues planning
Target version:
-
Start date:
Due date:
% Done:
0%
Estimated time:
Resolution:
Duplicate
Affected version:
Description
Hi,
we've encountered some misbehaviour regarding the estimated timein Redmine.
I've attached an image which shows several bugs, which seems to relate to the validation of this values.
Here is the reference list, how to reproduce this:- Enter 999999999999999999999999999999999999999 on the estimated time, this produce an arithmetic overflow which doesn't raise an error and is automatic set to FLOAT_MAX
- Enter 9999999999 (10 times a 9) as estimated time. This should stay 9999999999 but it's getting rounded up to 10000000000
- Enter 999999999999 (12 times a 9) as estimated time. This should stay 999999999999 but it's getting down to some other weird value 999999995904, there are missing 4095 hours. This seems to be related to the exponential display. Both are 1E+12. This seems to be related to float. Float isn't the best datatype to use for such values. Consider to change the column datatype to decimal, which is supported in the current database. This is much more precise and haven't such conversion errors.
- This is the tryage to get the rounding. This references to 2.
- The helper for the estimated time doesn't check the correctness of the string. For example, you can define hours by 2h30m to get 2.5 or 3h5m to get 3.08 as timevalue. But if you enter abc or 3j (misstyped) the string isn't checked. The issue just returns "update successfully" and sets the estimated time to nil. The string should be checked and should raise some error, if the input isn't correct.
Another idea could be, to limitate the estimated hours to some maximum value. An issue with nearly 1 million hours, seems to be wrong. ;-)
Best regards,
Daniel
Files
Related issues
Actions