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

RESOLVED FIXED in Bugzilla 4.2

Status

()

Bugzilla
Reporting/Charting
RESOLVED FIXED
14 years ago
4 years ago

People

(Reporter: Joel Peshkin, Assigned: Frédéric Buclin)

Tracking

({ue})

2.17.4
Bugzilla 4.2
Bug Flags:
approval +
approval4.4 +
approval4.2 +
blocking3.1.1 -

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
This still happens on the tip
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
Version: 2.17.1 → 2.17.4
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
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.
[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
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;
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
I'm going to rely on cust res to fix this for me, as is being done over in bug
106589 ;-)

Gerv
Severity: normal → minor
Priority: P3 → --
Target Milestone: Bugzilla 2.18 → Future

Updated

11 years ago
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
(Assignee)

Updated

10 years ago
Duplicate of this bug: 389227

Comment 9

10 years ago
this sucks. (and yes, that means on my next hacking spree or if someone reminds me, i'll see about hacking it.)
Flags: blocking3.1.1?
Keywords: ue

Comment 10

10 years ago
No, it's minor, so not a blocker.
Flags: blocking3.1.1? → blocking3.1.1-
(Assignee)

Updated

10 years ago
Assignee: gerv → charting
(Assignee)

Updated

9 years ago
Duplicate of this bug: 451545
(Assignee)

Updated

9 years ago
Duplicate of this bug: 346451
(Assignee)

Comment 13

4 years ago
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. ;)
Assignee: charting → LpSolit
Status: NEW → ASSIGNED
Attachment #735449 - Flags: review?(glob)
(Assignee)

Updated

4 years ago
Severity: minor → normal
Summary: HTML report with Resolution on vertical links to improper query → Tabular reports do not link bug counts involving the empty resolution correctly
Target Milestone: --- → Bugzilla 4.2
(Assignee)

Updated

4 years ago
Attachment #735449 - Flags: review?(glob) → review?(dkl)
Comment on attachment 735449 [details] [diff] [review]
patch, v1

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

r=dkl
Attachment #735449 - Flags: review?(dkl) → review+
(Assignee)

Updated

4 years ago
Flags: approval4.4+
Flags: approval4.2+
Flags: approval+
(Assignee)

Comment 15

4 years ago
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified report.cgi
Committed revision 8619.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.4/
modified report.cgi
Committed revision 8552.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.2/
modified report.cgi
Committed revision 8212.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.