If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Original estimate field too narrow to store values over 999.99

RESOLVED FIXED in Bugzilla 3.6

Status

()

Bugzilla
Creating/Changing Bugs
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Andras Keri, Assigned: Max Kanat-Alexander)

Tracking

Bugzilla 3.6
Bug Flags:
approval +

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: 3.4

The "original estimate" field (bugs.estimated_time) is defined as decimal(5,2), which results in truncating all values above 1000 hours to 999.99.

Splitting the bug would be advisable, but is not an option this time, this is why I'd ask to add one more digit to the field.

Reproducible: Always

Steps to Reproduce:
1.Enter a value above 1000 hours to original estimate
2.Check for email with this new value
3.Check table again and see 999.99 hours
(Reporter)

Updated

8 years ago
Version: unspecified → 3.4
(Assignee)

Comment 1

8 years ago
Quick question--are you using MySQL, PostgreSQL, or Oracle as your backend?
Severity: normal → enhancement
OS: Windows XP → All
Hardware: x86 → All
(Reporter)

Comment 2

8 years ago
MySQL.

One more thing: the field bugs.remaining_time also needs to be enlarged.

Comment 3

8 years ago
N.B. This occurs on MySQL 5.1, but not 4.1.

From MySQL docs (when I was researching the same problem at Yahoo!):

"A consequence of the change in handling of the DECIMAL and NUMERIC fixed-point data types is that the server is more strict to follow standard SQL. For example, a data type of DECIMAL(3,1) stores a maximum value of 99.9. Before MySQL 5.0.3, the server allowed larger numbers to be stored. That is, it stored a value such as 100.0 as 100.0. As of MySQL 5.0.3, the server clips 100.0 to the maximum allowable value of 99.9. If you have tables that were created before MySQL 5.0.3 and that contain floating-point data not strictly legal for the data type, you should alter the data types of those columns."
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
Just a note: the issue is not that 1000 is displayed as 999.99, but that projects with above 1000 hours available cannot be tracked.
(Assignee)

Comment 5

8 years ago
Okay, so we need to change it to decimal(7,3).
Severity: enhancement → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 6

8 years ago
Created attachment 416794 [details] [diff] [review]
v1
Assignee: create-and-change → mkanat
Status: NEW → ASSIGNED
Attachment #416794 - Flags: review?(dkl)
(Assignee)

Comment 7

8 years ago
Though this affects 3.4 and earlier, I only want to fix it for now on 3.6, because I don't like introducing schema changes on stable branches unless I have to.
Target Milestone: --- → Bugzilla 3.6
Comment on attachment 416794 [details] [diff] [review]
v1

Looks good and fixes the issue properly in my testing. I may apply this to our 3.4 installation as well just in case we run into this problem ourselves. r=dkl
Attachment #416794 - Flags: review?(dkl) → review+

Updated

8 years ago
Flags: approval?
(Assignee)

Updated

8 years ago
Flags: approval? → approval+
(Assignee)

Comment 9

8 years ago
The patch required a bit of un-bitrotting on checkin.

Checking in Bugzilla/DB/Schema.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Schema.pm,v  <--  Schema.pm
new revision: 1.130; previous revision: 1.129
done
Checking in Bugzilla/Install/DB.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/DB.pm,v  <--  DB.pm
new revision: 1.83; previous revision: 1.82
done
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.