Open
Bug 1143304
Opened 10 years ago
Updated 9 years ago
Axis options & vertical label checkbox not working correctly on bar chart report
Categories
(bugzilla.mozilla.org :: General, defect)
Tracking
()
NEW
People
(Reporter: emorley, Unassigned)
Details
Attachments
(2 files)
(deleted),
application/x-perl
|
Details | |
(deleted),
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
STR:
1) Open https://bugzilla.mozilla.org/query.cgi?format=report-graph
2) Pick "Tree Management" as the product & "Treeherder" as the component.
3) Pick just "FIXED" as the resolution.
4) Choose "bar chart" at the top of the page.
5) Set "vertical axis" to assignee real name.
6) Leave everything else on defaults (ie horizontal axis=none, vertical labels=unchecked).
7) Press generate report (resultant URL is: https://bugzilla.mozilla.org/report.cgi?y_axis_field=assigned_to_realname&cumulate=0&z_axis_field=&format=bar&x_axis_field=&query_format=report-graph&short_desc_type=allwordssubstr&short_desc=&product=Tree+Management&component=Treeherder&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&action=wrap )
8) Repeat the above, but this time with "vertical axis" left at None, and horizontal axis set to assignee real name.
9) Repeat again, but with vertical labels checked
Expected:
At least one of the permutations above gives me a bar chart where I can actually read the assignee names (ie: assignee names on the Y axis, with the label text oriented the right way up, so it fits nicely on the screen).
Actual:
* Whichever way around I have the axis options, the assignee real name labels are always on the X axis, and squished together, so they are unreadable.
* If I check the "vertical labels" option then the graph doesn't appear at all.
Reporter | ||
Comment 1•10 years ago
|
||
Interestingly, if I use "Assignee" rather than "Assignee real name", then the "vertical labels" option no longer causes the graph to not appear. However the axis options still don't work.
Comment 2•10 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #0)
> Actual:
> * Whichever way around I have the axis options, the assignee real name
> labels are always on the X axis, and squished together, so they are
> unreadable.
Having 1D graphs displayed this way is intentional, see bug 173005:
if ($row_field && !$col_field) {
# 1D *charts* should be displayed horizontally (with an col_field only)
$col_field = $row_field;
$row_field = '';
}
I guess this is how GD::Graph works. CC'ing gerv as he wrote that code.
> * If I check the "vertical labels" option then the graph doesn't appear at
> all.
I cannot reproduce using the example you gave, neither on bmo nor locally. This is working fine.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Comment 3•10 years ago
|
||
Yes... it's a very, very long time ago but I think the problem is that GD::Graph doesn't do horizontal bar charts. That's a poor comment, though. "Why", Gerv, not "what". Duh.
However, he is right that checking "vertical labels" causes problems:
https://bugzilla.mozilla.org/report.cgi?component=Treeherder&cumulate=0&product=Tree%20Management&query_format=report-graph&resolution=FIXED&x_labels_vertical=1&y_axis_field=assigned_to_realname&format=bar&ctype=png&action=plot&width=600&height=350
gives an image error. That needs looking at.
Ed: in the mean time, I suggest getting CSV output from chart.cgi and graphing it yourself in your favourite spreadsheet.
Gerv
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 4•10 years ago
|
||
Stripping down the URL, this one still breaks:
https://bugzilla.mozilla.org/report.cgi?product=Bugzilla&x_labels_vertical=1&y_axis_field=assigned_to&format=bar&ctype=png&action=plot
So it's not to do with product, and it's not to do with the specific y_axis_field. x_labels_vertical definitely seems to be the culprit. It seems to result in 0-byte files. But I can't reproduce the problem on my local install. Do we need to get someone to look at the BMO error log?
Gerv
Updated•10 years ago
|
Assignee: charting → nobody
Component: Reporting/Charting → General
Product: Bugzilla → bugzilla.mozilla.org
QA Contact: default-qa
Version: unspecified → Production
Comment 5•10 years ago
|
||
glob: do you agree that looking at the BMO logs is the next step? Who can do that?
Gerv
Flags: needinfo?(glob)
(In reply to Gervase Markham [:gerv] from comment #5)
> glob: do you agree that looking at the BMO logs is the next step? Who can do
> that?
that url doesn't generate any errors in our logs on production, but it's reproducible using the bmo developer's dump.
12:51 GD Warning: one parameter to a memory allocation multiplication is negative or zero, failing operation gracefully
not very useful, but it does smell like a GD bug to me.
you can view the data sent to GD by passing debug=1 to report.cgi:
https://bugzilla.mozilla.org/report.cgi?product=Bugzilla&x_labels_vertical=1&y_axis_field=assigned_to&format=bar&ctype=png&action=plot&debug=1
you should be able to reproduce the issue by fudging the value of %data in report.cgi.
Flags: needinfo?(glob)
bmo doesn't carry any customisations to the reports, moving back upstream.
Assignee: nobody → charting
Component: General → Reporting/Charting
Product: bugzilla.mozilla.org → Bugzilla
QA Contact: default-qa
Version: Production → 4.2.13
Comment 8•10 years ago
|
||
(In reply to Byron Jones ‹:glob› from comment #6)
> you can view the data sent to GD by passing debug=1 to report.cgi:
>
> https://bugzilla.mozilla.org/report.
> cgi?product=Bugzilla&x_labels_vertical=1&y_axis_field=assigned_to&format=bar&
> ctype=png&action=plot&debug=1
>
> you should be able to reproduce the issue by fudging the value of %data in
> report.cgi.
Doing this on my local installation (taking the data from the above URL and fudging it into the plotting code) renders the graph correctly. :-|
Note: at line 350 on trunk, you need:
@image_data = (
[
[
'Alex.Eiser@nasa.gov',
...
]
]
);
I had one two few nesting levels for a while, which broke and confused me.
checksetup says:
Checking for GD (v1.20) ok: found v2.46
Checking for Chart (v2.4.1) ok: found v2.4.6
Checking for Template-GD (any) ok: found v1.56
Checking for GDTextUtil (any) ok: found v0.86
Checking for GDGraph (any) ok: found v1.44
testserver.pl says:
TEST-OK GD version 2.46, libgd version 2.1.1-dev; Major versions match.
Gerv
Gerv
Comment 9•10 years ago
|
||
glob: what version of GD are we using in production, and can we update it?
You seem to be the only person who can reproduce this. I can't, locally.
Gerv
Flags: needinfo?(glob)
Comment 10•10 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #9)
> glob: what version of GD are we using in production, and can we update it?
> You seem to be the only person who can reproduce this. I can't, locally.
bmo's running GD v2.45, but i can reproduce this with GD v2.50 so upgrading prod is unlikely to help.
can you share your fudged trunk test? if your test works for me then it's likely the test fudging isn't correct, and i'll have something to build on to figure out what's going on.
Flags: needinfo?(glob)
Comment 11•9 years ago
|
||
Here's a copy of report.cgi from the bmo-4.2 branch with the data from https://bugzilla.mozilla.org/report.cgi?product=Bugzilla&x_labels_vertical=1&y_axis_field=assigned_to&format=bar&ctype=png&action=plot&debug=1 fudged in. It renders a graph correctly on my local install of the bmo-4.2 branch.
Gerv
Flags: needinfo?(glob)
Comment 12•9 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #4)
> Stripping down the URL, this one still breaks:
>
> https://bugzilla.mozilla.org/report.
> cgi?product=Bugzilla&x_labels_vertical=1&y_axis_field=assigned_to&format=bar&
> ctype=png&action=plot
this url doesn't work because you haven't provided width and height parameters, which are mandatory. this means all the diagnostic work from comment 4 onwards should be ignored.
--
what's actually happening is the real-name of one of our users is rather very long:
'Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!)'
and the graph isn't tall enough to render.
https://bugzilla.mozilla.org/report.cgi?component=Treeherder&cumulate=0&product=Tree%20Management&query_format=report-graph&resolution=FIXED&x_labels_vertical=1&y_axis_field=assigned_to_realname&format=bar&ctype=png&action=plot&width=600&height=350
if we increase the height to 400 it "works"
https://bugzilla.mozilla.org/report.cgi?component=Treeherder&cumulate=0&product=Tree%20Management&query_format=report-graph&resolution=FIXED&x_labels_vertical=1&y_axis_field=assigned_to_realname&format=bar&ctype=png&action=plot&width=600&height=400
--
i suspect the fix here should be to truncate names to (rolls die) 30 characters.
Flags: needinfo?(glob)
Comment 13•9 years ago
|
||
As you suggest. :-)
Gerv
Updated•9 years ago
|
Attachment #8643058 -
Flags: review?(glob) → review?(LpSolit)
Comment 14•9 years ago
|
||
Comment on attachment 8643058 [details] [diff] [review]
Patch v.1
Since Bugzilla 4.4, the "taller", "fatter" & co links are gone. The image is automatically generated as a 1024 x 600 px image and is automatially resized to fit the web browser window. This means that graphs support much longer strings than 30 characters. As glob said in comment 12, setting height=400 is already enough to display a 70 characters long string. So the default height=600 is probably wide enough for all real cases.
Feel free to take this patch for bmo, but upstream 4.2 is restricted to security fixes only, and 4.4 are newer are not "vulnerable" to this problem.
Attachment #8643058 -
Flags: review?(LpSolit) → review-
Comment 15•9 years ago
|
||
Moving this bug to bmo if you want it.
Component: Reporting/Charting → General
Product: Bugzilla → bugzilla.mozilla.org
QA Contact: default-qa
Version: 4.2.13 → Production
You need to log in
before you can comment on or make changes to this bug.
Description
•