[#4919] Custom report harness for easy integration of site-specific reporting
Summary Custom report harness for easy integration of site-specific reporting
Queue Whups
Type Enhancement
State Accepted
Priority 1. Low
Requester php@ideacode.com
Created 2007-01-19 (5392 days ago)
Updated 2007-01-20 (5391 days ago)
Patch No

php@ideacode.com 2007-01-19 14:30:25
When I have my tech lead hat on, I'm concerned about three things: 1) 
what's underway, 2) what's late, and 3) what's over budget.  Currently 
whups natively tracks #1 (state) and #2 (due date), but #3 is 
user-defined (*).  It is difficult to see all of these factors 

Having the ability to turn on additional columns (see also Issue 
4586), such as Due Date and the user-defined time-related columns, 
would help.  However, for our needs, a custom report is probably the 
best option (**).

The thrust of this ticket is to support a custom report harness, 
allowing a site to easily drop in custom reports. The harness should 
be able to:

1. locate site reports (perhaps through a configuration variable with 
a default location)

2. interrogate the reports for their name, description, and other details

3. present a selection of available custom reports from the Reports page

4. allow a custom report to fill a block on the My Tickets page

Custom reports should be assumed to be interactive; they may have 
their own form input widgets that operate outside of whups' native 
controls.  A base class/delegate presenting the glue between whups and 
the report would be beneficial for expediting development of these 

Additionally, whups could come with a selection of these reports 
"standard".  Careful selection of canned reports would allow whups to 
become out-of-box-ready for managers.

(*) We use three very simple attributes: Original Estimate, Current 
Estimate, and Actual.  We have specially tagged comment blocks that 
are in a known format. We track line items of work and then a cron job 
goes through and sums up the hours for each ticket and fills in the 
Actual attribute.  hermes is, right now, overkill for our needs.

(**) In our case, a table with tickets in one column and hours 
remaining in another, with each hours cell color coded to indicate if 
it's past due or near due would work.