Redmine

Hi Wilson,

If you have a Ticket (or more general Tracker), the Status-values have a certain lifecycle. It may be "new" when entered into the system, "authorized" by a manager to allow working on, set to "in progress" by a developer and "resolved" and then "closed" when finished. Otherwise it could be "obsolete", "refused" or "doublette". Depending on the type of tracker the Workflow may be more or less complicated/simple. E.g. for a Software-feature-request the workflow could be different than from a simple Todo (an other custom tracker). Not every status may followed by every other, so you can define a bug first to be "resolved" and then (if client agrees) set to "closed" and not immediately allow to set it to "closed".

Furthermore you have to think about roles: who is allowed to set which status transition?

So basically you should think about the lifecycle of your ticket-types, roles involved (manager, developer, ...) and then define workflow accordingly.

hope this helps

Alex