Closed Bug 215918 Opened 21 years ago Closed 21 years ago

ALL graphs that show numeric value on x-axis are useless and misleading

Categories

(Bugzilla :: Reporting/Charting, defect)

defect
Not set
minor

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: njaras, Assigned: gerv)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624 ALL graphs that show numeric value on x-axis are useless and misleading, because the x-axis is arranged in wrong order. Example: the graph showing anything against votes will show the x-axis as: 1,10,11,12,....19,2,21,22,23,...29,3,30,31,.... In other words, any graph with a numerical value in its x-axis is useless and misleading! http://bugzilla.mozilla.org/query.cgi?format=report-graph Reproducible: Always Steps to Reproduce: 1.Select any numerical value in x-axis for a chart 2.Plot the chart 3. Actual Results: As explained above, the numerical values are shown in a totally wrong order. As a result, all levels and trends shown in the chart are misleading. Expected Results: Show the numerical values in ascending/descending order (should be user-selectable) Alternatively, pad the values with leading zeros, which will sort them in correct order. I saw another bug related to this (Bug#142394; Bug count should be sortable), which is left unattended for last 15 MONTHS. However, the originator of that bug does not explain that this results in misleading, worthless charts. The suggested work-around (export to CSV file and make a chart in Excel or equivalent) *is* feasible, but leaves a major problem unresolbved: by that logic, graphing module was not at all required--the users could have exported data every time and constructed their own graphs! Please do not mark this as a duplicate of bug#142394!
This is a valid bug; however, Votes is the only numerical option available for the X axis, so the problem only occurs with Votes. That makes it fairly minor. One solution would be to remove the "Votes" option from the X axis altogether. Gerv
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
That should be OK, as the export to CSV is already provided. Any interested parties can always take the data and make their own graphs. Another *important* factor to be considered is that when Bugzilla is used in an organization (as opposed to its use to manage bugs in a open-source freeware), the "voting" factor is irrelevant, as bugs are prioritized based on techno-commercial factors by designated persons, rather by majority vote. Then again, Bugzilla's future version will have addition of user-definable fields. In that case, some organization may want to add some numeric fields, which would require plotting. All said and done, better to add the sorting feature now and be ready for the future.
Attached patch Patch v.1 (obsolete) — Splinter Review
Previously, all axes were sorted according to an alphabetic sort. This patch changes the behaviour so that Bugzilla detects if a field is numeric, and uses a numeric sort instead. This fixes the problem with the votes. Gerv
Comment on attachment 130995 [details] [diff] [review] Patch v.1 Jouni - are you still doing Bugzilla stuff, and could you review this? I seem to remember you reviewing my graphing fixes before. Gerv
Attachment #130995 - Flags: review?(jouni)
Comment on attachment 130995 [details] [diff] [review] Patch v.1 >Jouni - are you still doing Bugzilla stuff, and could you review this? Yeah; I've just been so busy that I've barely been able to do anything. I try to help when somebody asks though, especially with Win32 reviews and testing. >+my $col_numeric = 1; >+my $row_numeric = 1; >+my $tbl_numeric = 1; Nit: How about "xxx_isnumeric"? These are essentially booleans, but they could look more like ones. >+ $col_numeric = $col_numeric && ($col =~ /^\d+(\.\d+)?$/o); >+ $row_numeric = $row_numeric && ($row =~ /^\d+(\.\d+)?$/o); >+ $tbl_numeric = $tbl_numeric && ($tbl =~ /^\d+(\.\d+)?$/o); Is there a reason for these not to accept negative numbers? For votes that's irrelevant, but so is decimal support - let's go the generic way. I propose adding a -? after the ^. Nit: Make it "$col_numeric &&= ..." for more Perl guru points and extra brevity :-) With those, r=jouni.
Attachment #130995 - Flags: review?(jouni) → review+
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Attached patch Patch v.2Splinter Review
With review comments, and warnings eliminated. Gerv
Attachment #130995 - Attachment is obsolete: true
Attachment #131007 - Flags: review+
Carried over jouni's review; requesting approval. Gerv
Flags: approval+
Oops. That should be a ? for approval. :-) Gerv
Flags: approval+ → approval?
Flags: approval? → approval+
Fixed. Checking in report.cgi; /cvsroot/mozilla/webtools/bugzilla/report.cgi,v <-- report.cgi new revision: 1.19; previous revision: 1.18 done Gerv
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: