Changes between Version 1 and Version 2 of TracWorkflow
- Timestamp:
- 10/15/14 04:07:04 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracWorkflow
v1 v2 11 11 Graphically, that looks like this: 12 12 13 [[Image(htdocs:../common/guide/original-workflow.png)]] 13 {{{#!Workflow width=500 height=240 14 leave = * -> * 15 leave.operations = leave_status 16 leave.default = 1 17 accept = new -> assigned 18 accept.permissions = TICKET_MODIFY 19 accept.operations = set_owner_to_self 20 resolve = new,assigned,reopened -> closed 21 resolve.permissions = TICKET_MODIFY 22 resolve.operations = set_resolution 23 reassign = new,assigned,reopened -> new 24 reassign.permissions = TICKET_MODIFY 25 reassign.operations = set_owner 26 reopen = closed -> reopened 27 reopen.permissions = TICKET_CREATE 28 reopen.operations = del_resolution 29 }}} 14 30 15 31 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? … … 21 37 Graphically, it looks like this: 22 38 23 [[Image(htdocs:../common/guide/basic-workflow.png)]] 39 {{{#!Workflow width=700 height=300 40 leave = * -> * 41 leave.operations = leave_status 42 leave.default = 1 43 accept = new,assigned,accepted,reopened -> accepted 44 accept.permissions = TICKET_MODIFY 45 accept.operations = set_owner_to_self 46 resolve = new,assigned,accepted,reopened -> closed 47 resolve.permissions = TICKET_MODIFY 48 resolve.operations = set_resolution 49 reassign = new,assigned,accepted,reopened -> assigned 50 reassign.permissions = TICKET_MODIFY 51 reassign.operations = set_owner 52 reopen = closed -> reopened 53 reopen.permissions = TICKET_CREATE 54 reopen.operations = del_resolution 55 }}} 24 56 25 57 == Additional Ticket Workflows == … … 52 84 - del_resolution -- Clears the resolution field 53 85 - set_resolution -- Sets the resolution to the selected value. 54 - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. 55 {{{ 56 Example: 57 86 - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example: 87 {{{ 58 88 resolve_new = new -> closed 59 89 resolve_new.name = resolve … … 61 91 resolve_new.permissions = TICKET_MODIFY 62 92 resolve_new.set_resolution = invalid,wontfix 63 }}}93 }}} 64 94 - leave_status -- Displays "leave as <current status>" and makes no change to the ticket. 65 95 '''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results. … … 85 115 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. 86 116 87 While creating or modifying a ticket workf ow, `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.117 While creating or modifying a ticket workflow, `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. 88 118 89 119 This can be done as follows (your install path may be different). … … 118 148 === How to combine the `tracopt.ticket.commit_updater` with the testing workflow === 119 149 120 The [[ source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] is the optional component that [[TracRepositoryAdmin#trac-post-commit-hook|replaces the old trac-post-commit-hook]], in Trac 0.12.150 The [[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] is the optional component that [[TracRepositoryAdmin#trac-post-commit-hook|replaces the old trac-post-commit-hook]], in Trac 0.12. 121 151 122 152 By default it reacts on some keywords found in changeset message logs like ''close'', ''fix'' etc. and performs the corresponding workflow action. … … 124 154 If you have a more complex workflow, like the testing stage described above and you want the ''closes'' keyword to move the ticket to the ''testing'' status instead of the ''closed'' status, you need to adapt the code a bit. 125 155 126 Have a look at the [[ 0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 recipe]] for the `trac-post-commit-hook`, this will give you some ideas about how to modify the component.156 Have a look at the [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 recipe]] for the `trac-post-commit-hook`, this will give you some ideas about how to modify the component. 127 157 128 158 == Example: Add simple optional generic review state == … … 165 195 leave.default = 1 166 196 leave.operations = leave_status 167 reassign = new,assigned, reopened -> new197 reassign = new,assigned,accepted,reopened -> assigned 168 198 reassign.operations = set_owner 169 199 reassign.permissions = TICKET_MODIFY … … 211 241 == some ideas for next steps == 212 242 213 New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component. If desired, add a single-line link to that ticket here. Also look at the [ th:wiki:AdvancedTicketWorkflowPlugin] as it provides experimental operations.243 New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component. If desired, add a single-line link to that ticket here. Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations. 214 244 215 245 If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket. … … 230 260 231 261 * Actions should be selectable based on the ticket type (different Workflows for different tickets) 232 ''Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s `triage` operation.'' 233 262 ''Look into the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin]'s `triage` operation.'' 263 264 * I'd wish to have an option to perform automatic status changes. In my case, I do not want to start with "new", but with "assigned". So tickets in state "new" should automatically go into state "assigned". Or is there already a way to do this and I just missed it? 265 ''Have a look at [http://trac-hacks.org/wiki/TicketCreationStatusPlugin TicketCreationStatusPlugin] and [http://trac-hacks.org/wiki/TicketConditionalCreationStatusPlugin TicketConditionalCreationStatusPlugin]'' 266 267 * I added a 'testing' state. A tester can close the ticket or reject it. I'd like the transition from testing to rejected to set the owner to the person that put the ticket in 'testing'. The [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] is close with set_owner_to_field, but we need something like set_field_to_owner. 268 269 * I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state.
