Hi, Just wondering if anyone had a chance to read this? I realise it's pretty long winded, but I'd really appreciate some feedback here :)
Col Colin Guthrie wrote: > Hi, > > I'm looking for opinions/suggestions here and I'll try and keep this > short and to the point (I tend to ramble so please accept my apologies > if I do that here!). > > Background: I use Trac in my company to track time spent on task for > clients which we then use to bill them. In the beginning I used the > TimingAndEstimationPlugin and as I learned a little more about Trac I > wrote the WorkLogPlugin (which closely integrated with T&E) and > ClientsPlugin. All together it works pretty well :) > > With 0.11 now released I wanted to convert my WorkLogPlugin across to > using tracking different blocks of time that the ticket takes in it's > different states. Using an "inwork" state and measuring the time the > ticket is in that state is a bit like a log of work. > > Now T&E plugin (which is not mine but is developed by "Bobby Smith" > (real name Russ) on this list), uses the ticket changes field in an > ingenious way to track the hours worked. It's evolved from 0.10 and > allows billing reports to be pulled off. Essentially it uses two custom > fields on a ticket. One is a "hours" field and has a label "Add hours to > ticket". The other is "totalhours" and has a suitable label. Whenever > someone wants to add more hours to the ticket they enter the value in > the "hours" field and a ticket change listener will automatically take > that value and add it on to the total hours so that a cumulative value > is stored and displayed on the ticket which is handy. The value for > "hours" in ticket_changes can be used in e.g. billing reports over a > pre-defined time period (e.g. 1st of the month to the last day) to know > all the billable hours for a given ticket. It's all quite handy. > > My worklog plugin just hooked into this mechanism and all was well. > > However, I now find myself having requests from users to have different > "pools" of time to track: e.g. so that development and testing can be > tracked separately. Fitting in with the ticket workflow as mentioned > above seems like a nice way to do this (e.g. just define an inwork and > intesting states in your workflow). > > So assuming this is how I progress, I'm now tracking time spent in > arbitrary states. I don't want to have to add two custom fields for each > state I track with a changelistener doing all the accumulation work. I > think it's acceptable with the T&E plugin but trying to extend it here > seem like it's bordering on abuse :) > > So here are some options I've come up with and would appreciate some > thoughts/feedback on it, especially from the main devs. > > 1) Just use the timestamps of the ticket state transitions to work out > how long a ticket spend in a given state. > Pros: > * Simple (the info is there!) > Cons: > * How do I migrate an older 0.10 WorkLog installation to the new one? > * People make mistakes and forget to stop "working" sometimes, can I > allow a change of state with an adjusted date in the past? Can I update > the date later? I would have thought that ticket_changes should be > thought of as read-only. > * Complex to integrate directly into billing reports without preparsing. > > > 2) Create a generic "ticket_custom_timed" table. This table would be > almost a combination of ticket_change and ticket_custom: it would store > key/values against a ticket that are all equally valid (unlike > ticket_changes in which the latter supersedes the former). Every time I > "work" on a ticket, I would add a value into this table to record I'd > done something. > ticket | time | name | value > > So I would have a change listener to know when I'd come out of a > "tracked" state and I'd work out the amount of time I'd been in that > state (taking into consideration a corrective factor if I've > accidentally worked for too long on it!) and record that value in the table. > > Pros: > * Can record what we need flexibly. > * Has clear migration path from old custom fields. > Cons: > * It's harder for two independent plugins to share a table definition > (tho' entirely possible). > * Cannot hook into ticket model to add extra data into the structure > and thus transparently expose this via e.g. XML RPC/JSON etc. We can > hook into the ticket display via filters etc. but that limits things to > the web interface. > * Custom ticket fields would allow time to be recorded via XML RPC > etc. (basically the same limitation as above). > > > > > Now overall I've pretty much convinced myself that, despite it's flaws, > option 2 is better. A plugin could be created whose sole purpose is to > manage this table and provide a few utility functions. Other plugins > that want to use this can require it as a dependency. That's OK IMO. > This allows two or more plugins to share the table definition and thus > solves that problem. > > In theory Filters could be added that allowed special fields to be added > to visual form in order to provide a way to enter in manually the hours > you've spent on a ticket (this is generally not used in WorkLog plugin > but is how T&E plugin works). This would require hooking writing a > ticket change listener and checking the req.args to see if our value has > been changed, but I'm not sure this would even fire because technically > none of the actual ticket fields had changed :s Also it would work > nicely with e.g. XML RPC etc. as req.args may not actually be available > here (i.e. a ticket change listener should not look at req at all, but > just inspect the ticket object it's been given!). > > > > As you can tell I'm in a bit of a quandary as to how to progress! I've > tried to describe my problem here, but it's probably a bit easier to > understand if you know the T&E and WorkLog plugins a little! > > I am usually on IRC but am sometimes "away". Just poke me via my nick > which is coling and I'll respond if I'm about! > > I would be happy to patch ticket/model.py to include the concept of a > ticket_timed_custom field into the core model but I suspect will be > generally frowned upon. The only alternative I can see is littering the > model with extension points (e.g. ITicketModelExtension which various > predefined methods for loading, saving, populating fields etc.). This > would still require filters to display your extensions on the ticket > page but at least the model would support it. Actually if this was done > right, perhaps even ticket_custom could be implemented as an > ITicketModelExtension??? > > OK, I've done what I didn't meant to do which is ramble so I'll quit out > now. Thanks for braving this message and reading this far :) > > Col > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
