Open Bug 271673 Opened 20 years ago Updated 10 years ago

Remove low counts from tabular reports.

Categories

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

2.19.1
enhancement

Tracking

()

People

(Reporter: CodeMachine, Unassigned)

References

Details

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.
QA Contact: mattyt-bugzilla → default-qa
That's something we really want for 3.2. I will try to fix it myself if nobody else wants to.
Whiteboard: [roadmap 3.2]
Target Milestone: --- → Bugzilla 3.2
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
(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.
Whiteboard: [roadmap 3.2] → [roadmap: 3.2]
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.
Whiteboard: [roadmap: 3.2]
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Assignee: gerv → guy.pyrzak
Priority: -- → P2
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.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
Assignee: guy.pyrzak → charting
Target Milestone: Bugzilla 5.0 → ---
You need to log in before you can comment on or make changes to this bug.