Changes between Version 1 and Version 2 of TracWorkflow

Timestamp:

Oct 30, 2007, 6:32:27 PM (17 years ago)

Author:

trac

Comment:

—

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'''.
+=== Environments upgraded from 0.10 ===
+When you run `trac-admin <env> upgrade`, your `trac.ini` will be modified to include a `[ticket-workflow]` section.
+The workflow configured in this case is the original workflow, so that ticket actions will behave like they did in 0.10.
+
+Graphically, that looks like this:
 
 [[Image(htdocs:../common/original-workflow.png)]]
 
-You will probably want to look at the additional ticket workflows available, and `contrib/workflow/simple.ini` in particular.
+There are some significant "warts" in this; such as accepting a ticket sets it to 'assigned' state, and assigning a ticket sets it to 'new' state.  Perfectly obvious, right?
+So you will probably want to migrate to "basic" workflow; `contrib/workflow/migrate_original_to_basic.py` may be helpful.
+
+=== Environments created with 0.11 ===
+When a new environment is created, a default workflow is configured in your trac.ini.  This workflow is the basic workflow (described in `basic-workflow.ini`), which is somewhat different from the workflow of the 0.10 releases.
+
+Graphically, it looks like this:
+
+[[Image(htdocs:../common/basic-workflow.png)]]
 
 == Additional Ticket Workflows ==
@@ -60 +72 @@
 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 GraphViz understands to provide a visual description of the workflow.
+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.
 
 == Advanced Ticket Workflow Customization ==
@@ -66 +78 @@
 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.
 
-But if even that is not enough, you can disable DefaultTicketActionController, and create a plugin that completely replaces it.
+But if even that is not enough, you can disable the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it.