Standard reports

[Stuart Donaldson]

Christian Robottom Reis wrote:

>On Fri, Nov 19, 2004 at 02:40:17PM -0800, Stuart Donaldson wrote:
>  
>
>>I then created a pre-defined reports page which allows selecting a 
>>product, and a report for which it then will generate the report. It 
>>uses a small modification  to buglist.cgi in order to load the query 
>>based on the product selected and report selected, much like buglist.cgi 
>>can load a named query.
>>    
>>
>
>It's an interesting approach; I thought of something different, which
>I'll explain here. I have a long-term idea that we should have more
>"domain-specific" pages in Bugzilla: a page for viewing a User, a page
>for viewing a Product, a page for viewing a Group. These pages' main
>goal would be to provide general information on the entity, with links
>to ready-made reports and interesting statistics (for a Product,
>answering the questions how many open bugs? how many all-time closed
>bugs? can I see a full report of them?) and other entity-related tasks
>(file a bug on this product, edit this product -- for admins).
>  
>
...

>Bringing us back into the concrete world, by this I mean that I would
>prefer seeing a page with links to ready-made reports kept as a template
>(so it is rather easily customizable and reduces the requirement of Yet
>Another Administrative Interface for these reports) in something like
>show_product.cgi. 
>
>Too blue-skyish?
>
>  
>
In general, I like your idea.  I believe there is a need for a 'Product 
Overview' page that gives general stats for a product as well.  This is 
next on my internal wish-list for reporting. 

I had considered this approach for the problem I was trying to solve, 
but I also had a requirement that you should be able to combine multiple 
products into the reports.  So in my implementation, you can actually 
select one or more products, and then select which report to run.  It is 
fairly simple in implementation in that it builds up a query string to 
be processed by buglist.cgi.

I think having the 'domain specific pages' concept is a good one, but I 
couldn't see how it would provide the same functionality and solve the 
same problem that I was shooting for here.

As to the 'too blue-skyish' I think it is a good concept, but I do not 
think that you need another administrative interface for the reports in 
order to get the functionality installed.  The approach I took of 
defining the reports in a structure in localconfig is great to get the 
concept of pre-defined reports out and available.  I don't need a GUI to 
set them up.  Now I would argue that a GUI would be a nice to have, and 
should be worked on eventually.  However, we shouldn't overlook the 
power of doing simple configuration changes by editing pre-defined 
sources like localconfig or the templates.

-Stuart-