Tickets :: Comment on [#4919] Custom report harness for easy integration of site-specific reporting

* Your Email Address
* Spam protection	Enter the letters below: \ /.___..___.__ .__ >< \| [__ [ __[__) / \ \| [___[_./\| \
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.
Attachment
Watch this ticket

Saved Queries