On 4/29/13, Gary Martin <[email protected]> wrote: [...] > > It might be worth noting that periodic creation of these reports is not > the primary aim, unless of course I am missing something. The way I > interpret the core idea of the ticket is to provide users with a simple > way of producing reports which can show another query as a function of > time, where the timeslices within which to bin the data are configurable > in size. As that would only give us a single column of data, it would > also be good to be able to choose an additional column from the original > query to group by in order to show comparative data. So we would then be > able to get a table of data showing stuff like: > > * the number of tickets that are created and resolved for a given > product per day > * the number of tickets that are open and closed for a given product > on each day > * the number of tickets assigned to or resolved by a particular user > per day > > and many other variations. >
This looks really nice to me . The repository might be yet another target . > For the moment these reports could be regenerated each time it is > requested (this could be optimised later if it seems worthwhile). ;) > If we > have that kind of base then, beyond that, there are lots of directions > you could go to build into a larger project if this doesn't seem a big > enough project. This could include the periodic report creation or > notification, or perhaps plotting the data. Especially when it comes to data visualizations I look forward to put all those values in our «almost ready» charts . Any kinds of data tables would be enough , since our library is able to transform such data sets into «meaningful» (wrt the chart) data. Variations can be handled in a relatively easy way . > It would be interesting to > hear what else you can come up with though. > we are two , in the queue ;) -- Regards, Olemis.
