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 -~----------~----~----~----~------~----~------~--~---
