I've run into this kind of thing before. "Workflow" is a dynamic process with branches and decisions based on states. A configuration file is a static serialization of data.
The AdvancedTicketWorkflow plugin is is great in that it expands the possibilities of what can be done given the current framework. On the other hand, I've been wondering how hard it would be to have the workflow be a macro or other easy to configure piece of code? Incidentally, this would also solve the problem brought up in the thread: [Trac] Re: parent/child tickets to make WBS, rolled up estimates? One would like to be able to do all of the following: Case 1: Ticket #A depends on tickets #B, #C, and #D all being done. In the lingo of the MasterTicketPlugin, tickets #B, #C, and #D block #A Case 2: Tickets #B, #C, and #D all depend on #A being done. Or, #A blocks #B, #C, #D Case 3: Ticket #A is essentially comprised of tickets #B, #C, #D. When #B, #C, #D are closed, then #A is automatically closed. Cases 1 and 2 can be done with the MasterTicketPlugin. Case 3, which Greg brought up in the thread mentioned above, views tickets as "tasks" rather than bug reports or enhancement requests, the Trac default paradigm. In this default paradigm, for Case 3, one should either close #A, or close all of #B, #C, #D, and mark them as duplicates. From a "bug tracking" scheme that is fine. From a project management scheme, that defeats the purpose of defining sub tasks. Allowing for ticket management to be controlled by an optional, isolated bit of code that defines the workflow would allow either scenario. I have never tried to hack Trac source code. If anyone has some ideas for how to implement this, I'd take those ideas and give it a try. --AB Eric Hoch wrote: > Hello, > > I'd like to modify the default ticket workflow, but have not had > success so far. In the default workflow a ticket is assigned, then the > assignee can mark the ticket as resolved which will store the > resolution and then close the ticket. I would like to modify the last > step of that process so that instead of closing the ticket, it is > instead reassigned to someone else so that whatever changes have been > made can be packaged into a build. This process could continue for a > few more hops before it finally gets closed, but I'm only really > concerned with the first hand-off right now (I expect the others will > follow logically.) > It's worth noting that I also have the AdvancedTicketWorkflow > plugin installed in my trac instance, which opens up a few more > operations that could be used. > > To restate my request differently: When a ticket is resolved, I > would like the resolution stored (normal), and the ticket reassigned > to another user (Component Owner). How would I accomplish this in the > trac.ini file? > > Thanks in advance, > > Eric > > > -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Ariel I Balter, Ph.D. Postdoc Biological Monitoring/Modeling Fundamental and Computational Sciences Directorate Pacific Northwest National Laboratory Mail: PO Box 999, MS P7-58,Richland, WA 99352 Shipping: 790 6th Street, MS P7-58, Richland, WA 99354 Tel: 509-376-7605 Cell: 509-713-0087 [email protected] www.arielbalter.com www.pnl.gov --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
begin:vcard fn:Ariel Balter, PhD n:Balter;Ariel email;internet:[email protected] tel;home:812-332-2721 tel;cell:812-219-4558 x-mozilla-html:TRUE url:http://arielbalter.com version:2.1 end:vcard
