6.0.0-git
2019-01-23

[#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
Owners
Requester php (at) ideacode (dot) com
Created 2007-01-19 (4387 days ago)
Due
Updated 2007-01-20 (4386 days ago)
Assigned
Resolved
Milestone
Patch No

History
2007-01-20 15:42:41 Jan Schneider State ⇒ Accepted
 
2007-01-19 14:30:25 php (at) ideacode (dot) com Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Custom report harness for easy integration of site-specific reporting
Queue ⇒ Whups
Reply to this comment
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 
concurrently.



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 
reports.



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.

Saved Queries