Edgewall Software

Changes between Initial Version and Version 3 of Ticket #6548

Apr 1, 2008, 9:24:49 AM (12 years ago)
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:

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


  • Ticket #6548

    • Property Status newreopened
    • Property Summary different type of ticketdifferent types of ticket need different workflows
    • Property Priority highnormal
    • Property Milestone 0.110.12
    • Property Keywords workflow added
    • Property Type taskenhancement
  • Ticket #6548 – Description

    initial v3  
    1 different type of ticket have different UI
     1Actions should be selectable based on the ticket type (different Workflows for different tickets.
    3 different type of ticket have different workflow
     3This 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.