271673 - Remove low counts from tabular reports.

Status: NEW

(Bugzilla :: Reporting/Charting, enhancement, P2)

Description

[Matthew Tuck [:CodeMachine]]

I tried to generate a report on who had filed the most bugs on Bugzilla (vain
me).  As a result I got a massive report consisting of loads of 1 and 2 counts
that could have happily been omitted.  It would be nice to be able to remove these.

You can't just remove a cell, so it makes sense to restrict an entire
table/multi-row/multi-col.

I suggest the best way to do this is for each dimension, have three fields,
total must be at least [1], min must be at least [1], and max must be at least
[1], that could restrict the results.

Might be worthwhile to allow displaying these three stats in the dimension
headers too.

Comment 1

[Frédéric Buclin]

That's something we really want for 3.2. I will try to fix it myself if nobody else wants to.

Comment 2

[Gervase Markham [:gerv]]

I don't think I'll get to this.

Why not do it with dynamic HTML on the client-side, so people can adjust the parameters in real time if they load a data set and find it noisy?

Gerv

Comment 3

[Frédéric Buclin]

(In reply to comment #2)
> Why not do it with dynamic HTML on the client-side, so people can adjust the
> parameters in real time if they load a data set and find it noisy?

This feature should also be available for graphs. So making it available server-side makes sense to me. But this is not exclusive, both can be implemented.

Comment 4

[Frédéric Buclin]

I just looked at templates, and I don't see how we can easily implement this feature, even dynamically, as a lot of stuff is done in the templates themselves, such as dynamically calculating totals for rows and columns instead of having this done in the CGI script itself, which would save a lot of trouble.

Comment 5

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 8

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.