Edgewall Software

Opened 16 years ago

Last modified 7 years ago

#6548 new enhancement

different types of ticket need different workflows — at Version 3

Reported by: anonymous Owned by: Jonas Borgström
Priority: normal Milestone: unscheduled
Component: ticket system Version: 0.11b1
Severity: normal Keywords: workflow
Cc: awatts@…, trac@…, leho@…, itamarost@…, marc31boss@…, Ryan J Ollos Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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.

Change History (1)

comment:3 by Christian Boos, 16 years ago

Description: modified (diff)
Keywords: workflow added
Milestone: 0.110.12
Priority: highnormal
Status: newreopened
Summary: different type of ticketdifferent types of ticket need different workflows
Type: taskenhancement

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

Note: See TracTickets for help on using tickets.