Changes between Version 3 and Version 4 of TracWorkflow
- Timestamp:
- Jun 22, 2007, 10:22:42 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracWorkflow
v3 v4 5 5 6 6 == The Default Ticket Workflow == 7 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'''. 7 === Environments upgraded from 0.10 === 8 When you run `trac-admin <env> upgrade`, your `trac.ini` will be modified to include a `[ticket-workflow]` section. 9 The workflow configured in this case is the original workflow, so that ticket actions will behave like they did in 0.10. 8 10 9 [[Image(original-workflow.png)]] 11 Graphically, that looks like this: 10 12 11 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. 13 [[Image(source:trunk/trac/htdocs/original-workflow.png)]] 14 15 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? 16 So you will probably want to migrate to "basic" workflow; `contrib/workflow/migrate_original_to_basic.py` may be helpful. 17 18 === Environments created with 0.11 === 19 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. 20 21 Graphically, it looks like this: 22 23 [[Image(source:trunk/trac/htdocs/basic-workflow.png)]] 12 24 13 25 == Additional Ticket Workflows == 14 26 15 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.27 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. 16 28 17 29 == Basic Ticket Workflow Customization == … … 19 31 Create a `[ticket-workflow]` section in `trac.ini`. 20 32 Within this section, each entry is an action that may be taken on a ticket. 21 For example, consider the `accept` action from [source:trunk/contrib/workflow/simple-workflow.ini simple-workflow.ini]:33 For example, consider the `accept` action from `simple-workflow.ini`: 22 34 {{{ 23 35 accept = new,accepted -> accepted … … 32 44 - del_owner -- Clear the owner field. 33 45 - set_owner -- Sets the owner to the selected or entered owner. 46 - ''actionname''`.set_owner` may optionally be set to a comma delimited list or a single value. 34 47 - set_owner_to_self -- Sets the owner to the logged in user. 35 48 - del_resolution -- Clears the resolution field 36 49 - set_resolution -- Sets the resolution to the selected value. 50 - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. 37 51 - leave_status -- Displays "leave as <current status>" and makes no change to the ticket. 38 52 '''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results. … … 58 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. 59 73 60 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.74 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. 61 75 62 76 == Advanced Ticket Workflow Customization == 63 77 64 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.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. 65 79 66 But if even that is not enough, you can disable !DefaultTicketActionController, and create a plugin that completely replaces it.80 But if even that is not enough, you can disable DefaultTicketActionController, and create a plugin that completely replaces it.