Edgewall Software

Opened 15 years ago

Last modified 6 years ago

#6548 new enhancement

different types of ticket need different workflows

Reported by: anonymous Owned by:
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.

Attachments (2)

MultipleWorkflowPlugin.rar (4.7 KB ) - added by ermaltesi@… 14 years ago.
plugin that replace the ConfigurableTicketPlugin
redmine-workflow.png (24.9 KB ) - added by Marc Plano-Lesay <marc31boss@…> 11 years ago.
Related graphics: Redmine multiple workflow definition UI

Download all attachments as: .zip

Change History (19)

comment:3 by Christian Boos, 15 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:

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

comment:4 by Christian Boos, 15 years ago

Milestone: 0.122.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 awatts <awatts@…>, 14 years ago

Cc: awatts@… added

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

  • ticket/default_workflow.py

    186186                else:
    187187                    allowed = 1
     189                ticket_type = action_info.get('ticket_type')
     190                if ticket_type:
     191                    ticket_type = [x.strip() for x in ticket_type.split(',')]
     192                    if ticket.values['type'] not in ticket_type:
     193                        allowed = 0
    189195                if allowed:
    190196                    allowed_actions.append((action_info['default'],
    191197                                            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.

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

by ermaltesi@…, 14 years ago

Attachment: MultipleWorkflowPlugin.rar added

plugin that replace the ConfigurableTicketPlugin

comment:8 by ermaltesi@…, 14 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:9 by osimons, 14 years ago

Resolution: fixed
Status: closedreopened

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.

comment:10 by anonymous, 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 Patrick May, 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:

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

comment:12 by Patrick May <trac@…>, 14 years ago

Cc: trac@… added

comment:13 by Christian Boos, 13 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:14 by lkraav <leho@…>, 13 years ago

Cc: leho@… added

comment:15 by Christian Boos, 13 years ago

Milestone: triagingunscheduled

Milestone triaging deleted

comment:16 by Itamar Ostricher, 13 years ago

Cc: itamarost@… added

comment:18 by Marc Plano-Lesay <marc31boss@…>, 11 years ago

Cc: marc31boss@… added

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 Marc Plano-Lesay <marc31boss@…>, 11 years ago

Attachment: redmine-workflow.png added

Related graphics: Redmine multiple workflow definition UI

comment:19 by dongping.xie.tud@…, 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 Ryan J Ollos, 9 years ago

Cc: Ryan J Ollos added

comment:21 by Ryan J Ollos, 8 years ago

Owner: Jonas Borgström removed
Status: reopenednew

comment:22 by Ryan J Ollos, 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 set_resolution attribute.

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.