Question about workflow customization.

[Greg]

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

[jevans]

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

[yoh...@gmail.com]

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.

[Greg Brigley]

Thanks!