Changes between Version 1 and Version 2 of TracWorkflow

Timestamp:

04/14/08 09:36:50 (2 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.
 
-[[Image(htdocs:../common/original-workflow.png)]]
+Graphically, that looks like this:
 
-You will probably want to look at the additional ticket workflows available, and `contrib/workflow/simple.ini` in particular.
+[[Image(htdocs:../common/guide/original-workflow.png)]]
+
+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/guide/basic-workflow.png)]]
 
 == 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 `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.
 
 == Basic Ticket Workflow Customization ==
@@ -37 +49 @@
  - set_resolution -- Sets the resolution to the selected value.
    - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value.
+{{{
+Example:
+
+resolve_new = new -> closed
+resolve_new.name = resolve
+resolve_new.operations = set_resolution
+resolve_new.permissions = TICKET_MODIFY
+resolve_new.set_resolution = invalid,wontfix
+}}}
  - leave_status -- Displays "leave as <current status>" and makes no change to the ticket.
 '''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results.
@@ -60 +81 @@
 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.
+
+This can be done as follows (your install path may be different).
+{{{
+cd /var/local/trac_devel/contrib/workflow/
+sudo ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini
+}}}
+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).
+
+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.
 
 == 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) that may not be merely simple state changes.  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.
+