Tabular reports return blank tables
Categories
(bugzilla.mozilla.org :: General, defect)
Tracking
()
People
(Reporter: dveditz, Assigned: dkl)
Details
Attachments
(2 files)
The old tabular reports are returning no data, just empty cells. If you click on the "Bar" or "Line" links under the table the search results are plotted as expected, but when you click on "Table" it goes back to zeros.
I have a few of these bookmarked (mostly for security bugs) and they all appear affected. The above link is just a simplified demo of the problem
| Assignee | ||
Updated•1 year ago
|
Comment 1•1 year ago
|
||
| Assignee | ||
Comment 2•1 year ago
|
||
| Assignee | ||
Comment 3•1 year ago
|
||
Reopening. Something is still off. The numbers are shifted and not correct for their appropriate columns. Things looked correct in my simple testing locally but with the larger numbers of production it still not right. I will investigate some more.
| Comment hidden (obsolete) |
| Reporter | ||
Comment 5•1 year ago
|
||
I take that back, the previous comment was a product of a joyous 10-second glance.
On a "Status x Resolution" table like the one in comment 0 the numbers for resolved bugs are correct (if you account for the column shift), but the query links are all wrong. All the links have the term &resolution=undefined instead of the expected resolution for the column (FIXED, DUPLICATE, etc) and clicking on them returns zarro boogs. The link query does not match the query used to generate the table numbers. If I edit the query to the correct resolution then the numbers match the table shifted by a column.
There are no results in the table for the OPEN bugs. Maybe the internal query also used "undefined" instead of "---" ?
The Bar chart is now slightly wrong: there is an extra "---" set of bars with all zero results on the left side. The rest looks like plausible numbers but I didn't check them.
The Line chart also has an extra "---" column of 0 values on the left.
| Assignee | ||
Comment 6•1 year ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #5)
I take that back, the previous comment was a product of a joyous 10-second glance.
On a "Status x Resolution" table like the one in comment 0 the numbers for resolved bugs are correct (if you account for the column shift), but the query links are all wrong. All the links have the term
&resolution=undefinedinstead of the expected resolution for the column (FIXED, DUPLICATE, etc) and clicking on them returns zarro boogs. The link query does not match the query used to generate the table numbers. If I edit the query to the correct resolution then the numbers match the table shifted by a column.There are no results in the table for the OPEN bugs. Maybe the internal query also used "undefined" instead of "---" ?
The Bar chart is now slightly wrong: there is an extra "---" set of bars with all zero results on the left side. The rest looks like plausible numbers but I didn't check them.
The Line chart also has an extra "---" column of 0 values on the left.
Yep I have a fix going up for review soon that fixes the shifted error and the undefined so I think all will be back to normal. Depending on review, I might be able to get it deployed today.
| Reporter | ||
Comment 7•1 year ago
|
||
I picked another random set of attributes and in "assignee x severity" the columns were correct. The query links (other than assignee total) were all wrong, with a "&bug_severity=undefined" value.
If I swap x and y axes then the query links have "&assignee=undefined" (column values still in the right place though).
Picking another random combination (cc_count x Component) it's always the x-axis term that is "&<field>=undefined" in the links
Comment 8•1 year ago
|
||
| Assignee | ||
Comment 9•1 year ago
|
||
Ok, merged a proper fix this time and will be in the next deployment.
https://github.com/mozilla-bteam/bmo/commit/1f0f80e2533e50e76518ef9e4272183b7079f558
| Assignee | ||
Comment 10•1 year ago
|
||
This fix is now live in production. Please let me know if you see any further issues.
| Reporter | ||
Comment 11•1 year ago
|
||
This is working correctly now. Thank you!
Description
•