I've noticed the introduction of most doomed reports, and I think it would be useful to extend these to more general summary reports. This would work as follows: Firstly, you would have a selection criteria like you have for queries. Then you would have a bunch of reporting fields. For each of these you report a value and how many bugs have this value. For fields that are sets (ie cc field), you could report for one document more than once. If you have more than one column, the second is a subcategory. Perhaps an example is in order. Selection: area is {browser, mailnews}, status is {open, reopened, ..} Categorise On: Milestone, CC 1004 bug reports found M9 - 900 engineer1@domain1.com - 40 engineer2@domain2.com - 101 ... M10 - 400 ... Everything gets sorted automatically within it's category. This is basically the same as a most doomed report where you take all bugs and report on Milestone, Engineer. You could also specify a limit on the first field, so you would only report, say, the first milestone. For this to work exactly like the most doomed report, you'd need to ensure you can't reopen bugs with a milestone of M8 during M9.

Each category name should be hyperlinkified, ie in the example above, you'd have a link for M9 bugs, then a link for M9 bugs assigned to engineer1@domain1.com.

See bug #9789 and bug #15806 for two different specific reports that this would support.

Also useful would be the ability to just summarise, and not include the individual bugs, ie just the categories and their counts.

Actually you'd probably want the ability to limit the display of every category, as well as the documents themselves. For example a Top 10 voted for report summarised on Product would be Product -> Max 10 (Documents) You could also do: Milestone (Max 5), Engineer (Max 10) -> Max 10 (Documents) You could possibly provide a a link to expand these maxima.

I don't know what I was talking about two comments up since my original proposal didn't show the individual bugs. But it definitely should be able to, for example for most voted reports.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

and also 9789

*** Bug 17604 has been marked as a duplicate of this bug. ***

Well, this sounds very much like SQL, doesn't it? SELECT count(bug_id) FROM bugs ... WHERE ... GROUP BY ... ORDER BY ... Can you post the SQL queries for the examples here, compare them, and come up with a generic pattern for these queries? Or is there no such pattern? How many open bugs in product p, targeted at milestone m, are assigned to x? http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/reports.cgi#728 : select count(bug_id) from bugs,profiles where target_milestone=\"$ms\" and userid=assigned_to and userid=\"$person\" and bugs.product=".SqlQuote($FORM{'product'} and (bugs.bug_status = 'NEW' or bugs.bug_status = 'ASSIGNED' or bugs.bug_status = 'REOPENED') How many untargeted NEW non-enhancement Browser/MailNews bugs with empty status whiteboard are assigned to x? http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/reports.cgi#843 select count(bug_id) from bugs,profiles where bugs.bug_status='NEW' and userid=assigned_to and userid='$person' and target_milestone='' and bug_severity!='enhancement' and status_whiteboard='' and (product='Browser' or product='MailNews')

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one. Sorry for the spam.

moving to real milestones...

To the bugzilla 3 component

The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.

Taking all of cyeh's Bugzilla bugs.

Moving to new Bugzilla product ...

Would be nice if you could get percentages along with counts. And when you're categorising on multi-valued fields, an explicit message should appear saying that the sum of the categories may add up to more than the total because of this.

As a feature on the reports page, it would be nice to have monthly breakdowns of both charts and reports (even quarterly). Is there any new progress on reports for version 2.14? Any patches available yet or schedule for new patch features to be ready soon?

When the query.cgi templatisation gets checked in, generic reporting will soon become a reality. I am currently writing generic charting as we speak. Gerv

Sounds like this will probably make 2.16, resetting milestone appropriately.

Gerv, could you estimate the amount of time it would take you or another Bugzilla hacker to implement this feature?

Myk: this one's not that tricky. It basically involves: - splitting query.cgi so you can steal the middle bit of the interface - writing the code to select the two (or three) axes for the table of data - getting all the SQL and hard stuff from the patches someone submitted over in some bug whose number I've forgotten I got some way on that, and hope to get further on it this weekend. Gerv

Gerv, if you're doing the grunt work on this I'd be prepared to do some of the other stuff I wanted (idented report type, detail rows, etc) after you've finished for its first milestone release. I'm wondering whether each report type should be a different template, and let the report page automatically determine what report types are available. Another idea is that attachments are fast becoming first class citizens - we may want to add attachment reports at some stage, but that's probably off into the future.

Gerv: Maybe bug 92676 is the one you keep forgetting. :-)

This doesn't look like it'll make 2.16 -> 2.18

We should probably do stored reports too, for consistency's sake.

Here it is :-) Version 1 of the new reporting mechanism. Gerv

*** Bug 92676 has been marked as a duplicate of this bug. ***

This tweaks a few things. Known bugs: the names of the different types of report and the way they are accessed will change after bug 146945 cleans up the format system. Also, some of the names (e.g. format=report for query.cgi, and report.cgi for the report CGI) may be too generic. Neither of these things should prevent review. Gerv

I tried applying this to the tip (first v1 and then adding v2) and was unable to apply v2. This mechanism looks pretty cool, but I am not quite sure how to invoke it. I didn't see anything that uses search-report. If I understand this correctly, we should also tie this mechanism in to collectstats.

> I tried applying this to the tip (first v1 and then adding v2) and was unable > to apply v2. That's because the patches aren't cumulative :-) All patches I attach (to any bug) are standalone. Also, note the "obsolete" flag on v.1. Just apply v.2, and you'll be fine. > This mechanism looks pretty cool, but I am not quite sure how to invoke it. I > didn't see anything that uses search-report. It uses the format mechanism. http://bugzilla.mycompany.com/query.cgi?format=report > If I understand this correctly, we should also tie this mechanism in to > collectstats. Er... you don't :-) This displays data about the current state of Bugzilla. It has nothing to do with the historical data that collectstats collects. Gerv

Comment on attachment 99444 [details] [diff] [review] Patch v.2 Something is missing here. When I apply this patch, it does not include the search-report template. file error - search/search-report.html.tmpl: not found

Joel: my deepest apologies. A failure to cvs add the files meant they weren't included in the diff. Try this one. Gerv

I'm not sure where ValidateOutputFormat is supposed to come from.... Undefined subroutine &main::ValidateOutputFormat called at /home/bugzilla/tip/report.cgi line 118. Versions of modules follow..... Checking perl modules ... Checking for AppConfig (v1.52) ok: found v1.52 Checking for CGI::Carp (any) ok: found v1.20 Checking for Data::Dumper (any) ok: found v2.102 Checking for Date::Parse (any) ok: found v2.22 Checking for DBI (v1.13) ok: found v1.30 Checking for DBD::mysql (v1.2209) ok: found v2.1017 Checking for File::Spec (v0.82) ok: found v0.82 Checking for Template (v2.07) ok: found v2.07 Checking for Text::Wrap (v2001.0131) ok: found v2001.0131 The following Perl modules are optional: Checking for GD (v1.19) ok: found v1.19 Checking for Chart::Base (v0.99) ok: found v0.99 Checking for XML::Parser (any) ok: found v2.31

I see what is happening.... This conflicts with the checkin for bug 146945 which removed ValidateOutputFormat

Yes; if you are testing this, replace: +my $format = ValidateOutputFormat($::FORM{'format'}, "report", "reports"); with +my $format = GetFormat("reports/report", $::FORM{'format'}, $::FORM{'ctype'}); However, CSV won't work until I've renamed some of the files, I don't think. I will update the patch this evening. I work too fast for myself sometimes ;-) Gerv

This should work with the current tip. Gerv

I should add that the new access URL is: http://bugzilla.mycompany.com/query.cgi?format=report-table This is to avoid hogging the namespace; there may well be other types of report later. Gerv

Patch v.5 - unrotted, with a few UI tweaks. Gerv

Comment on attachment 100378 [details] [diff] [review] Patch v.5 r=joel There are a few items that I would like to see enhanced, but they can be handled as seperate bugs.

Fixed. Fantastic! :-) (This hopefully shouldn't conflict with Request Tracker - it only adds one error, and most other things are in new files.) Thanks again to rdean@cambiannetworks.com for inspiration and code. Checking in report.cgi; /cvsroot/mozilla/webtools/bugzilla/report.cgi,v <-- report.cgi initial revision: 1.1 done Checking in globals.pl; /cvsroot/mozilla/webtools/bugzilla/globals.pl,v <-- globals.pl new revision: 1.204; previous revision: 1.203 done Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.192; previous revision: 1.191 done Checking in query.cgi; /cvsroot/mozilla/webtools/bugzilla/query.cgi,v <-- query.cgi new revision: 1.107; previous revision: 1.106 done Checking in t/004template.t; /cvsroot/mozilla/webtools/bugzilla/t/004template.t,v <-- 004template.t new revision: 1.19; previous revision: 1.18 done Checking in Bugzilla/Search.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search.pm,v <-- Search.pm new revision: 1.18; previous revision: 1.17 done Checking in template/en/default/global/code-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/code-error.html.tmpl,v <-- code-error.html.tmpl new revision: 1.11; previous revision: 1.10 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-report-table.html.tmpl,v done Checking in template/en/default/search/search-report-table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-report-table.html.tmpl,v <-- search-report-table.html.tmpl initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/table.html.tmpl,v done Checking in template/en/default/reports/table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/table.html.tmpl,v <-- table.html.tmpl initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/table.csv.tmpl,v done Checking in template/en/default/reports/table.csv.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/table.csv.tmpl,v <-- table.csv.tmpl initial revision: 1.1 done Gerv

*** Bug 77764 has been marked as a duplicate of this bug. ***

If this is a dup of 77764, then technically, this should block the meta bug #75488

Wrong way round, dgk. Also, this bug is FIXED already. Gerv