92676 - Need summary table of bug counts

Status: RESOLVED DUPLICATE of bug 12282

(Bugzilla :: Reporting/Charting, defect, P3)

Description

[Rick Dean]

My manager needed a summary table of bug counts.  This is
what I came up with.  I received permission to redistribute it.
The URL has an example output.

Comment 1

[Rick Dean]

We have used the script for several months with wonderful results.

Comment 2

[Matthew Tuck [:CodeMachine]]

This ain't in CVS, so it ain't fixed.

This might be worth adding for 2.16, but all this should eventually be
superceded by general summary reports (bug #12282) which would allow this and
more.

Comment 3

[Rick Dean]

Thanks.  I was not aware of the other bug.

I will check it into CVS this weekend.

Comment 4

[Rick Dean]

Attachment: Patch for tables_of_bug_counts enhancement

Comment 5

[Rick Dean]

The attachment has the code.  I made a few more small enhancements,
and a bugfix, but stopped short of patching the index.html page.  :-)
Warning: the patch creates two new files.  

I had trouble determining who should review the code (and check into CVS)
before I resolved the bug.  Suggestions are welcome.

I added some defenses for large installations
like mozilla.  The script now pre-counts the bugs in the SQL server
to stop you from wasting your time.  The limit is adjustable at
the bottom of the form.  It would also be good to have limits for 
the number of rows and columns.  Please let me know if this is
needed for open source project bug databases.  My company only has
50 people, and it works well as is.

I don't like all the GenerateSQL() code I duplicated from buglist.cgi.
This would be to move into another file, and I would
be willing to try it if requested, but it is easier to install on a
2.12 or 2.10 implementation this way.

There are some queries which would work better by having the SQL 
server do the counts, but I am not that much of a SQL guru, and many
queries work better the current way.

The next big enhancement, would be to add time as another axis choice.

Comment 6

[Jacob Steenhagen]

This still hasn't passed through the review and check in stages, so it's not 
yet FIXED.  Re-opening so the patch can be evaluated (this bug already contains 
the patch and review keywords).

Comment 7

[Matthew Tuck [:CodeMachine]]

A reviewer will come to this bug ASAP.  But bear in mind that we're currently in
the process of finalising 2.14, so no code is being accepted that isn't
necessary for that, and when 2.16 begins we've 91 patches to review, so this may
take a little while.

Comment 8

[Rick Dean]

Attachment: example output of the new CGI

Comment 9

[Andreas Franke (gone)]

See also bug 77764.

Comment 10

[Andreas Franke (gone)]

Gerv, can this (or some other generic bugcounting mechanism) be checked in soon?

Comment 11

[Gervase Markham [:gerv]]

See bug 9789. I think doing what I suggest there would be a very good start. I'm
not sure if the cgi attached to this bug has general utility; perhaps it could
go into contrib.

Gerv

Comment 12

[Gervase Markham [:gerv]]

OK, I didn't quite get the point here. Here are some more sane comments:

I like the idea of this, but I think duplicating all that query page UI is the
wrong way to do it. What I'd ideally like to see is a "twisty" on the query page
which gives access to the extra UI needed to get a table instead of a buglist.

rdean: what do you think?

Gerv

Comment 13

[Andreas Franke (gone)]

See also the comments from Dave Miller 2001-09-07 20:02 in bug 16775, where he
talks about a search.cgi as a more generic successor of query.cgi.

Comment 14

[Rick Dean]

I agree the current patch duplicates way too much code, but for
patching old systems this way was easiest.   I offered before
to do the more extensive changes, but am worried they were
less likely to be accepted.

Combining the table and query forms is a good interface.  Maybe
if somebody did not select two axis, a traditional bug list would be 
formed.  I am anti-javascript biased, so my personal preference is
against twisties and hidden page info (like mouseover crud). 

Most of my developers no longer use the query page, but 
instead several root page links to tables.  It is quite popular
here and works well for small companies.  Maybe we should add
another field for maxRows and maxColumns which combines the
smallest totals into an "other" if the cgi is
unpopular for large projects like mozilla.
 
--Rick

Comment 15

[Andreas Franke (gone)]

I think a twisty doesn't have to use javascript. Maybe it could work like the
"Add another boolean chart" button?

Comment 16

[Matthew Tuck [:CodeMachine]]

Why do we need the buglist fields on the results page?  We don't have it
anywhere else - that's what the back button is for.

I'd rather see this on two pages just like query.

I also would like to see the buglist fields HTML moved to CGI.pl.  I want this
for when I generalise summary reports further.

Comment 17

[Andreas Franke (gone)]

What is "buglist fields"? Are you talking about the query form?

Comment 18

[Matthew Tuck [:CodeMachine]]

I am talking about the fields that determine what bugs are considered.

For example, on the query page, this is currently pretty much everything except
sort ordering, but would also not include things like column specifications,
colours, "count only" etc if and when they were added to the query page.

The idea is that these fields are reusable throughout the product.

Comment 19

[Rick Dean]

Attachment: new patch replaces old, has minimal duplicate code but different UI

Comment 20

[Gervase Markham [:gerv]]

The way forward here is to templatise query.cgi. When this is done, the common
UI can be factored out and made part of two templates - one for query.cgi and
one for tables.cgi .

Gerv

Comment 21

[Andreas Franke (gone)]

Gerv, I think the idea here was to offer the additional form elements for the
"table" stuff on the query page, but only upon request (the same way additional
boolean charts are only offered upon request currently). This is completely
independent of templates. If you are planning to templatize query.cgi in the
near future, feel free to do so, but otherwise I can't see a single reason why
this should wait.

Comment 22

[Gervase Markham [:gerv]]

query.cgi is being templatised as part of kiko and mpt's UI rewrite. If I made
mods to the query.cgi UI at the moment, it would mess them up. I'd rather wait
for them to land. I've told kiko his bug blocks this one, and he promised to
look at it this week.

Patience :-)

Gerv

Comment 23

[Andreas Franke (gone)]

1) The latest patch can be applied to current versions of CGI.pl, query.cgi and
buglist.cgi . You also need to chmod a+x counts_table.cgi .

If you are lucky, you can see this patch in action at 
	http://bugzilla.mathweb.org/query.cgi
(the "Use table of bug counts." link will turn on the tables stuff).

2) I can't find a "Target Milestone" selection on any of the axes. I can imagine
that this would be the most useful thing on installations like b.m.o. How hard
would it be to add support for that?

3) A bug: For empty QA contacts, it showed a count of "2" in one of the fields,
but when I clicked on it, the result was a list of 19 (!) bugs. Something is
wrong here.

4) kiko: is there any chance to get this checked into bugzilla before Myk
upgrades to the tip (bug 103885)?

Please let's try to avoit bitrotting this if at all possible...

Comment 24

[Andreas Franke (gone)]

Gerv, kiko, myk: 
If you don't want to mess with query.cgi at the moment, what about the following
solution: Until query.cgi is templatized, check in the previous patch
(attachment 44762 [details] [diff] [review]). That patch is pretty much just a single new extra file, so
it can easiliy be removed when the real patch lands. This way, we can have our
cake and eat it, too: query.cgi can be templatized first, and b.m.o can generate
bugcount tables.
If you like, you can even make it a hidden feature by not including the link to
table_of_bug_counts.cgi in the command menu in the footer.

Comment 25

[Rick Dean]

Attachment: Patch to newer patch (49554) for Andrea's concerns

Comment 26

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 27

[Gervase Markham [:gerv]]

I keep losing this bug! I would assign it to me, but I didn't make the patches.

Note to self: This is the bug you keep looking for, and you can find it by
searching comments for the (probably unique in Bugzilla ;-) string
"jesusislordatchristmas". ;-)

By the way, now that query.cgi has landed, I am working on integrating this stuff.

Gerv

Comment 28

[Rick Dean]

Cute.  Thanks.

Comment 29

[Andreas Franke (gone)]

I think this has some overlap with bug 125798 ("move buglist sub-routines into
re-usable module"). That one will probably land first. Marking dependency.

Comment 30

[Jouni Heikniemi]

There is nothing to look at here yet, since Gerv is in the process of
integrating the old patches into the new code. Removing review keyword for now.

Comment 31

[Gervase Markham [:gerv]]

The work for this is going on in bug 12282. It takes serious inspiration from
the code attached to this bug - so many thanks to rdean, who has a credit in the
source.

Gerv

*** This bug has been marked as a duplicate of 12282 ***

Comment 32

[Dave Miller [:justdave]]

removing target milestone from WONTFIX/INVALID/WORKSFORME/DUPLICATE bugs so
they'll show up as untriaged if they get reopened.