different types of ticket need different workflows

[anonymous]

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_task, new_defect, etc., and the workflow graph would separate at that point.

[Christian Boos]

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:

[ticket-type-workflow]
# old type . old state => new type . new state
defect.* = enhancement.*
enhancement.* = defect.*
*.new = task.new
*.closed = task.closed
*.* = task.inprogress

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 ;-)

[Christian Boos]

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.

[awatts <awatts@…>]

To restrict actions to a particular ticket type first patch default_workflow.py

ticket/default_workflow.py

@@ -186 +186 @@
                 else:
                     allowed = 1
 
+                ticket_type = action_info.get('ticket_type')
+                if ticket_type:
+                    ticket_type = [x.strip() for x in ticket_type.split(',')]
+                    if ticket.values['type'] not in ticket_type:
+                        allowed = 0
+
                 if allowed:
                     allowed_actions.append((action_info['default'],
                                             action_name))

Then in 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 defect. .ticket_type can be a comma separated list of ticket types.

[ermaltesi@…]

plugin that replace the ConfigurableTicketPlugin

[ermaltesi@…]

I risolved this creating a plugin called MultipleWorkflowPlugin, it works and i hope it doesn't have too much bugs

[osimons]

If anything, it is a worksforme resolution as the project has not really fixed anything.

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.

[anonymous]

please write a few words on how to use this plugin. a simple example of ini should be ok.

[Patrick May]

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:

Feature Request:

1. Request
2. List requirements (text documents)
3. Front end Design (visual comps)
4. Implementation
5. QA
6. Deploy

Bug Report:

1. Report
2. Reproduce
3. Fix
4. QA
5. Deploy

[Christian Boos]

Milestone 2.0 deleted

[Christian Boos]

Milestone triaging deleted

[Marc Plano-Lesay <marc31boss@…>]

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.

[Marc Plano-Lesay <marc31boss@…>]

Related graphics: Redmine multiple workflow definition UI

[dongping.xie.tud@…]

It would be a great feature. Then one can then use trac to manage routine tasks in the engineering too. (Like JIRA)

[Ryan J Ollos]

#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 set_resolution attribute.