212471 - Tabular reports do not link bug counts involving the empty resolution correctly

Status: RESOLVED FIXED

(Bugzilla :: Reporting/Charting, defect)

Description

[Joel Peshkin]

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]

This still happens on the tip

Comment 2

[Gervase Markham [:gerv]]

This problem arises because the DB value for the empty resolution is "". This
turns into a URL of:
...&resolution=&...
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?

Gerv

Comment 3

[Dave Miller [:justdave]]

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]]

[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
follows:

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.

Gerv

Comment 5

[Dave Miller [:justdave]]

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]]

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.

Gerv

Comment 7

[Gervase Markham [:gerv]]

I'm going to rely on cust res to fix this for me, as is being done over in bug
106589 ;-)

Gerv

Comment 9

[timeless]

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]

No, it's minor, so not a blocker.

Comment 13

[Frédéric Buclin]

Attachment: 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]]

Comment on attachment 735449 [details] [diff] [review]
patch, v1

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

r=dkl

Comment 15

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified report.cgi
Committed revision 8619.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.4/
modified report.cgi
Committed revision 8552.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.2/
modified report.cgi
Committed revision 8212.