Opened 15 years ago
Last modified 6 years ago
#6548 new enhancement
different types of ticket need different workflows
|Reported by:||anonymous||Owned by:|
|Cc:||awatts@…, trac@…, leho@…, itamarost@…, marc31boss@…, Ryan J Ollos||Branch:|
Description (last modified by )
Actions should be selectable based on the ticket type (different Workflows for different tickets.
This is becoming a frequent request, with clear usecases. The closest the current implementation will allow is to have a plugin provide a
triage action that sets the next state based on the ticket type, so a
new ticket would move to
new_defect, etc., and the workflow graph would separate at that point.
Change History (19)
comment:3 by , 15 years ago
|Milestone:||0.11 → 0.12|
|Priority:||high → normal|
|Status:||new → reopened|
|Summary:||different type of ticket → different types of ticket need different workflows|
|Type:||task → enhancement|
comment:4 by , 15 years ago
|Milestone:||0.12 → 2.0|
Not for 0.12.
Besides, the above suggestion could alternatively be done in a plugin which replaces the basic ConfigurableTicketWorkflow with a more advanced TicketTypeConfigurableWorkflow.
comment:5 by , 14 years ago
To restrict actions to a particular ticket type first patch
186 186 else: 187 187 allowed = 1 188 188 189 190 191 192 193 194 189 195 if allowed: 190 196 allowed_actions.append((action_info['default'], 191 197 action_name))
trac.ini where your workflow actions are defined you can add
.ticket_type to actions to restrict them one or more ticket types. Omitting this option leaves action behaving as it did before.
still_buggy = closed -> reopened still_buggy.name = Still Buggy still_buggy.ticket_type = defect ...
This means that the "Still Buggy" action will only appear on tickets where the type is
.ticket_type can be a comma separated list of ticket types.
by , 14 years ago
plugin that replace the ConfigurableTicketPlugin
comment:8 by , 14 years ago
|Status:||reopened → closed|
I risolved this creating a plugin called MultipleWorkflowPlugin, it works and i hope it doesn't have too much bugs
comment:9 by , 14 years ago
|Status:||closed → reopened|
If anything, it is a
worksforme resolution as the project has not really
A bit too soon to close the ticket anyway, let's leave it open for now in case others want to chime in on the issue.
comment:10 by , 14 years ago
please write a few words on how to use this plugin. a simple example of ini should be ok.
comment:11 by , 14 years ago
Just adding a note that this is a good feature.
There's a significant difference between the work of designing enhancements and reproducing bugs. Different people with different skillsets are involved, possibly funded from different budgets. So having a Multiple Workflow is attractive.
For example, on a current project the workflow is:
- List requirements (text documents)
- Front end Design (visual comps)
comment:12 by , 14 years ago
comment:13 by , 13 years ago
|Milestone:||2.0 → unscheduled|
Milestone 2.0 deleted
comment:14 by , 13 years ago
comment:15 by , 13 years ago
|Milestone:||triaging → unscheduled|
Milestone triaging deleted
comment:16 by , 13 years ago
comment:18 by , 11 years ago
This would be very usefull. A great improvment would be having a matrix as the one you can find in Redmine, where you have differents matrices for each user role and ticket type.
by , 11 years ago
Related graphics: Redmine multiple workflow definition UI
comment:19 by , 9 years ago
It would be a great feature. Then one can then use trac to manage routine tasks in the engineering too. (Like JIRA)
comment:20 by , 9 years ago
comment:21 by , 8 years ago
|Status:||reopened → new|
comment:22 by , 6 years ago
#9508 closed as a duplicate. If typed workflows are added, the allowed resolutions for each action that has a
set_resolution operation can be specified in the
set_resolution attribute (see workflow customization). See also #11856, which proposes to add a
default_resolution attribute and to rename the
Reusing this ticket for discussing the per-type workflow idea (TracWorkflow@17, reproduced in the description).
Instead of the 'new → new_task' scheme suggested by Eli, I think that we should instead provide a state "migration" table based on the type change.
I mean the ticket starts with an initial type, so why not select the appropriate workflow (
[<type>-ticket-worflow]?) from the start. Then, at any given time, if the ticket type changes, a state migration will happen (ignoring the selected action), according to some mapping done in the .ini:
Which makes me think that at this point, a db table describing the mapping "in full"" with some appropriate UI in Trac admin would probably be a better idea. And of course, same could be said for the workflow itself, but now I digress ;-)