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 | 01/19/2007 (6690 days ago) |
Due | |
Updated | 01/20/2007 (6689 days ago) |
Assigned | |
Resolved | |
Milestone | |
Patch | No |
State ⇒ New
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Custom report harness for easy integration of site-specific reporting
Queue ⇒ Whups
what's underway, 2) what's late, and 3) what's over budget. Currently
whups natively tracks
#1(state) and#2(due date), but#3isuser-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.