Changes between Version 1 and Version 2 of TracWorkflow
- Timestamp:
- Jul 4, 2007, 9:42:54 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracWorkflow
v1 v2 5 5 6 6 == The Default Ticket Workflow == 7 If you do not configure a custom workflow, the default workflow is described in `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. 10 11 Graphically, that looks like this: 8 12 9 13 [[Image(htdocs:../common/original-workflow.png)]] 10 14 11 You will probably want to look at the additional ticket workflows available, and `contrib/workflow/simple.ini` in particular. 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(htdocs:../common/basic-workflow.png)]] 12 24 13 25 == Additional Ticket Workflows == … … 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, `contrib/workflow/workflow_parser.py` may be useful. It can create `.dot` files that GraphVizunderstands 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 [http://www.graphviz.org GraphViz] understands to provide a visual description of the workflow. 61 75 62 76 == Advanced Ticket Workflow Customization == … … 64 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 the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it.