Changes between Version 1 and Version 2 of TracWorkflow
- Timestamp:
- Apr 22, 2013, 6:19:02 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracWorkflow
v1 v2 25 25 == Additional Ticket Workflows == 26 26 27 There are several example workflows provided in the Trac source tree; look in [trac:source:trunk/contrib/workflow contrib/workflow] for `.ini` config sections. One of those may be a good match for what you want. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. 27 There are several example workflows provided in the Trac source tree; look in [trac:source:trunk/contrib/workflow contrib/workflow] for `.ini` config sections. One of those may be a good match for what you want. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. However if you have existing tickets then there may be issues if those tickets have states that are not in the new workflow. 28 28 29 29 Here are some [http://trac.edgewall.org/wiki/WorkFlow/Examples diagrams] of the above examples. 30 30 31 31 == Basic Ticket Workflow Customization == 32 33 Note: Ticket "statuses" or "states" are not separately defined. The states a ticket can be in are automatically generated by the transitions defined in a workflow. Therefore, creating a new ticket state simply requires defining a state transition in the workflow that starts or ends with that state. 32 34 33 35 Create a `[ticket-workflow]` section in `trac.ini`. … … 92 94 And then open up the resulting `trac.pdf` file created by the script (it will be in the same directory as the `trac.ini` file). 93 95 96 An online copy of the workflow parser is available at http://foss.wush.net/cgi-bin/visual-workflow.pl 97 94 98 After you have changed a workflow, you need to restart apache for the changes to take effect. This is important, because the changes will still show up when you run your script, but all the old workflow steps will still be there until the server is restarted. 95 99 … … 99 103 100 104 {{{ 101 testing = new,accepted,needs_work -> testing105 testing = new,accepted,needs_work,assigned,reopened -> testing 102 106 testing.name = Submit to reporter for testing 103 107 testing.permissions = TICKET_MODIFY … … 111 115 pass.set_resolution = fixed 112 116 }}} 117 118 === How to combine the `tracopt.ticket.commit_updater` with the testing workflow === 119 120 The [[source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] is the optional component that [[TracRepositoryAdmin#trac-post-commit-hook|replaces the old trac-post-commit-hook]], in Trac 0.12. 121 122 By default it reacts on some keywords found in changeset message logs like ''close'', ''fix'' etc. and performs the corresponding workflow action. 123 124 If you have a more complex workflow, like the testing stage described above and you want the ''closes'' keyword to move the ticket to the ''testing'' status instead of the ''closed'' status, you need to adapt the code a bit. 125 126 Have a look at the [[0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 recipe]] for the `trac-post-commit-hook`, this will give you some ideas about how to modify the component. 113 127 114 128 == Example: Add simple optional generic review state == … … 217 231 * Actions should be selectable based on the ticket type (different Workflows for different tickets) 218 232 ''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.'' 233