Last Comment Bug 212471 - Tabular reports do not link bug counts involving the empty resolution correctly
: Tabular reports do not link bug counts involving the empty resolution correctly
: ue
Product: Bugzilla
Classification: Server Software
Component: Reporting/Charting (show other bugs)
: 2.17.4
: All All
: -- normal (vote)
: Bugzilla 4.2
Assigned To: Frédéric Buclin
: default-qa
: 346451 389227 451545 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2003-07-11 16:20 PDT by Joel Peshkin
Modified: 2013-05-05 14:36 PDT (History)
7 users (show)
LpSolit: approval+
LpSolit: approval4.4+
LpSolit: approval4.2+
mkanat: blocking3.1.1-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

patch, v1 (896 bytes, patch)
2013-04-09 15:13 PDT, Frédéric Buclin
dkl: review+
Details | Diff | Splinter Review

Description Joel Peshkin 2003-07-11 16:20:51 PDT
With the example URL, the resolution is on the vertical axis and includes
resolved and unresolved bugs alike.  

If you click on the unresolved blocker, you will see that you get all the
blockers resolved or not. 

An interesting note is that if the resolution is on the horizontal axis instead,
unresolved bugs do not even show up even though they are in the query and they
show up in the total.
Comment 1 Joel Peshkin 2003-07-12 07:34:28 PDT
This still happens on the tip
Comment 2 Gervase Markham [:gerv] 2003-08-25 12:03:29 PDT
This problem arises because the DB value for the empty resolution is "". This
turns into a URL of:
However, Bugzilla interprets this as "I don't care about the resolution." So,
the query brings back all bugs, not just unresolved ones.

I can't see an obvious non-hacky fix for this. We can't start interpreting
"&resolution=&" as "resolution is empty", or things will break. And I really
don't want to add special exceptions to the charting mechanism for this issue.

Myk, Dave: ideas?

Comment 3 Dave Miller [:justdave] ( 2003-08-25 12:11:15 PDT
The query page special-cases it, why can't reports?  query uses resolution=---
to indicate the blank resolution, and the backend converts it to "" before querying.
Comment 4 Gervase Markham [:gerv] 2003-08-25 12:26:09 PDT
[Note: the numbers in the report are all correct; it's just the buglist you get
when you click the link that's wrong.]

It's not that we _can't_, it's that I don't want to. The way this works is as

The back end assembles the "buglistbase", which is all of the query apart from
the variable bits (severity and resolution in this case.) In the template, the
link for each number is made by taking the buglistbase and appending
"&severity=blocker&resolution=FIXED", or whatever.

Therefore, I would have to put some code in the template, inside my lovely
generic loop which generates this stuff, to say:

[% IF row_field = "resolution" && row = "" %]
  [% row = "---" %]
[% END %]
[% IF col_field = "resolution" && col = "" %]
  [% col = "---" %]
[% END %]

(except it would be more complicated than that, because we need to preserve the
original value of row or col.)

That's really horrible. Like, _really_ horrible.

Comment 5 Dave Miller [:justdave] ( 2003-08-25 12:42:10 PDT
query.cgi does this on the perl backend before feeding it to the template:

push @::legal_resolution, "---"; # Oy, what a hack.
shift @::legal_resolution;
      # Another hack - this array contains "" for some reason. See bug 106589.
$vars->{'resolution'} = \@::legal_resolution;
Comment 6 Gervase Markham [:gerv] 2003-08-28 10:28:56 PDT
Indeed it does. That doesn't stop it being a really nasty hack, as outlined in
comment 4, here. 

Surely the correct fix is to disambiguate? I'm not sure how, though.

Comment 7 Gervase Markham [:gerv] 2004-01-25 09:52:08 PST
I'm going to rely on cust res to fix this for me, as is being done over in bug
106589 ;-)

Comment 8 Frédéric Buclin 2007-07-23 02:00:34 PDT
*** Bug 389227 has been marked as a duplicate of this bug. ***
Comment 9 timeless 2007-07-23 02:05:20 PDT
this sucks. (and yes, that means on my next hacking spree or if someone reminds me, i'll see about hacking it.)
Comment 10 Max Kanat-Alexander 2007-07-23 14:19:12 PDT
No, it's minor, so not a blocker.
Comment 11 Frédéric Buclin 2008-08-21 05:45:42 PDT
*** Bug 451545 has been marked as a duplicate of this bug. ***
Comment 12 Frédéric Buclin 2008-08-21 06:10:59 PDT
*** Bug 346451 has been marked as a duplicate of this bug. ***
Comment 13 Frédéric Buclin 2013-04-09 15:13:44 PDT
Created attachment 735449 [details] [diff] [review]
patch, v1

Let's be consistent with query.cgi and buglist.cgi, and use --- for the empty resolution. This magically fixes all the problems related to it, because the backend code already detects --- as the empty resolution. ;)
Comment 14 David Lawrence [:dkl] 2013-05-05 13:08:20 PDT
Comment on attachment 735449 [details] [diff] [review]
patch, v1

Review of attachment 735449 [details] [diff] [review]:

Comment 15 Frédéric Buclin 2013-05-05 14:36:20 PDT
Committing to: bzr+ssh://
modified report.cgi
Committed revision 8619.

Committing to: bzr+ssh://
modified report.cgi
Committed revision 8552.

Committing to: bzr+ssh://
modified report.cgi
Committed revision 8212.

Note You need to log in before you can comment on or make changes to this bug.