Changes between Version 2 and Version 3 of TracWorkflow

Timestamp:

May 23, 2007, 10:07:55 PM (17 years ago)

Author:

pacopablo

Comment:

Linked references to samples to the browser

TracWorkflow

@@ -5 +5 @@
 
 == The Default Ticket Workflow ==
-If you do not configure a custom workflow, the default workflow is described in `contrib/workflow/original-workflow.ini` '''FIXME'''.
+If you do not configure a custom workflow, the default workflow is described in [source:trunk/contrib/workflow/original-workflow.ini contrib/workflow/original-workflow.ini] '''FIXME'''.
 
 [[Image(original-workflow.png)]]
 
-You will probably want to look at the additional ticket workflows available, and `contrib/workflow/simple.ini` in particular.
+You will probably want to look at the additional ticket workflows available, and [source:trunk/contrib/workflow/simple-workflow.ini contrib/workflow/simple-workflow.ini] in particular.
 
 == Additional Ticket Workflows ==
 
-There are several example workflows provided in the Trac source tree; look in `contrib/workflow` for `.ini` config sections.  One of those may be a good match for what you want.
+There are several example workflows provided in the Trac source tree; look in [source:trunk/contrib/workflow contrib/workflow] for `.ini` config sections.  One of those may be a good match for what you want.
 
 == Basic Ticket Workflow Customization ==
@@ -19 +19 @@
 Create a `[ticket-workflow]` section in `trac.ini`.
 Within this section, each entry is an action that may be taken on a ticket. 
-For example, consider the `accept` action from `simple-workflow.ini`:
+For example, consider the `accept` action from [source:trunk/contrib/workflow/simple-workflow.ini simple-workflow.ini]:
 {{{
 accept = new,accepted -> accepted
@@ -58 +58 @@
 There are a couple of hard-coded constraints to the workflow.  In particular, tickets are created with status `new`, and tickets are expected to have a `closed` state.  Further, the default reports/queries treat any state other than `closed` as an open state.
 
-While creating or modifying a ticket workfow, `contrib/workflow/workflow_parser.py` may be useful.  It can create `.dot` files that [http://www.graphviz.org/ Graphviz] understands to provide a visual description of the workflow.
+While creating or modifying a ticket workfow, [source:trunk/contrib/workflow/workflow_parser.py contrib/workflow/workflow_parser.py] may be useful.  It can create `.dot` files that [http://www.graphviz.org/ Graphviz] understands to provide a visual description of the workflow.
 
 == Advanced Ticket Workflow Customization ==
 
-If the customization above is not extensive enough for your needs, you can extend the workflow using plugins.  These plugins can provide additional operations for the workflow (like code_review), or implement side-effects for an action (such as triggering a build).  Look at `sample-plugins/workflow` for a few simple examples to get started.
+If the customization above is not extensive enough for your needs, you can extend the workflow using plugins.  These plugins can provide additional operations for the workflow (like code_review), or implement side-effects for an action (such as triggering a build).  Look at [source:trunk/sample-plugins/workflow sample-plugins/workflow] for a few simple examples to get started.
 
 But if even that is not enough, you can disable !DefaultTicketActionController, and create a plugin that completely replaces it.