On Jan 7, 2:02 am, jevans <[email protected]> wrote: > On Jan 6, 5:27 pm, Greg <[email protected]> wrote: > > > > > Hi, > > > I'm a potential future user of Trac, currently using Bugzilla, and I > > have a question about Trac's workflow customization. > > > My company currently tracks bugs and features. While I like the idea > > of considering both bugs and features as subsets of a single "issue" > > concept, we need to use different terminology for the two. For > > instance, bugs would have states like "reported", "confirmed", > > "assigned", "fixed", and "closed", while features would have states > > like "requested", "approved", "assigned", "completed", "tested", and > > "merged". The reason for the distinction is partly to avoid confusing > > our staff, and partly for regulatory compliance. > > > Would I be able to configure a single installation of Trac to handle > > these two different workflows, or would I be better off to install > > Trac twice? > > > Thanks, > > > Greg > > Speculation: > Perhaps the TicketCreationStatus plug-in (<http://trac-hacks.org/wiki/ > TicketCreationStatusPlugin>) could be extended to support setting the > initial state based on ticket type. Or it might be useful as a > starting point for a separate plug-in that does it. I think setting > up separate workflows from there would be pretty straight-forward. > Good luck, > - jevans
Yes, this can be done. You will want to take a look at the TypedTicketWorkflow plugin (this the key for what you want to do, and pretty awesome, but can be unwieldy at first) and possibly also the TicketValidator plugin. I don't use the TicketCreationStatus plugin, but it is worth a look in addtion, if you want that sort of feature. you may also consider the TicketExtPlugin which can fill in some fields/description based on ticket type. We also use the AdvancedWorkflowPlugin to reassing/change state/resoultion on certain transitions (such as set_owner_to_previous, same for state, etc.) as well as limit what permissions are required to do certain actions Anway, as an example, with the first 2 I mentioned, we do the following: we have a Feature Branch type, which has the resolutions of only: merged, abandoned it also has the work flow stages: Ready for code Review Code Review Accepted (which is the only step, in our model, that can transition to merged) a task ticket, has the resolution of completed instead of "fixed", and also most of the others are gone. "canceled" is another resolution for a task a test ticket, has completed, pass, fail, canceled the validator is used for a few states, for example, to assign a ticket, a Due date is required to accept a ticket, an estimate time is required and to "send to QA" the how to verify section is required. Yes, this can be done. I recommend the following: map out your intended workflow. additionally give TICKET_ADMIN rights to move *->new (reopen), and/or install the batch modify plugin. when I did this, no matter how well we nailed down the workflow, we ended up with some transitions never thought of: (for example, we only expected our "Ready for code review" stage to ever transition to "review accepted" or back to "previous state/ owner" (reject set it back to "accepted or assigned or new...etc. as appropriate" or "abandoned, which is an axed feature). Turns out the "needInfo" state actually applied once. I used BatchModify to set it directly, but then added the transition option for future use. our workflow is quite complicated, and it was implementable. the custom-workflow section is huge though. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
