Changes between Version 1 and Version 2 of TracWorkflow

Timestamp:

May 30, 2012, 7:12:16 PM (13 years ago)

Author:

trac

Comment:

--

TracWorkflow

@@ -25 +25 @@
 == Additional Ticket Workflows ==
 
-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.
+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. 
 
 Here are some [http://trac.edgewall.org/wiki/WorkFlow/Examples diagrams] of the above examples.
 
 == Basic Ticket Workflow Customization ==
+
+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.
 
 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).
 
+An online copy of the workflow parser is available at http://foss.wush.net/cgi-bin/visual-workflow.pl
+
 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.
 
@@ -99 +103 @@
 
 {{{
-testing = new,accepted,needs_work -> testing
+testing = new,accepted,needs_work,assigned,reopened -> testing
 testing.name = Submit to reporter for testing
 testing.permissions = TICKET_MODIFY
@@ -111 +115 @@
 pass.set_resolution = fixed
 }}}
+
+=== How to combine the `tracopt.ticket.commit_updater` with the testing workflow ===
+
+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.
+
+By default it reacts on some keywords found in changeset message logs like ''close'', ''fix'' etc. and performs the corresponding workflow action.
+
+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. 
+
+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.
 
 == Example: Add simple optional generic review state ==
@@ -217 +231 @@
  * Actions should be selectable based on the ticket type (different Workflows for different tickets)
 ''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.''
+