Changes between Version 1 and Version 2 of TracWorkflow
- Timestamp:
- Sep 9, 2012, 11:47:55 PM (11 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? 16 So you will probably want to migrate to "basic" workflow; `contrib/workflow/migrate_original_to_basic.py`may be helpful.32 So you will probably want to migrate to "basic" workflow; [trac:source:trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] may be helpful. 17 33 18 34 === Environments created with 0.11 === … … 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 == 26 58 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. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. 59 There are several example workflows provided in the Trac source tree; look in [trac:source:trunk/contrib/workflow 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. However if you have existing tickets then there may be issues if those tickets have states that are not in the new workflow. 60 61 Here are some [http://trac.edgewall.org/wiki/WorkFlow/Examples diagrams] of the above examples. 28 62 29 63 == Basic Ticket Workflow Customization == 64 65 Note: Ticket "statuses" or "states" are not separately defined. The states a ticket can be in are automatically generated by the transitions defined in a workflow. Therefore, creating a new ticket state simply requires defining a state transition in the workflow that starts or ends with that state. 30 66 31 67 Create a `[ticket-workflow]` section in `trac.ini`. … … 48 84 - del_resolution -- Clears the resolution field 49 85 - 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. 51 {{{ 52 Example: 53 86 - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example: 87 {{{ 54 88 resolve_new = new -> closed 55 89 resolve_new.name = resolve … … 57 91 resolve_new.permissions = TICKET_MODIFY 58 92 resolve_new.set_resolution = invalid,wontfix 59 }}}93 }}} 60 94 - leave_status -- Displays "leave as <current status>" and makes no change to the ticket. 61 95 '''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results. … … 90 124 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). 91 125 126 An online copy of the workflow parser is available at http://foss.wush.net/cgi-bin/visual-workflow.pl 127 92 128 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. 93 129 … … 97 133 98 134 {{{ 99 testing = new,accepted,needs_work -> testing135 testing = new,accepted,needs_work,assigned,reopened -> testing 100 136 testing.name = Submit to reporter for testing 101 137 testing.permissions = TICKET_MODIFY … … 108 144 pass.operations = set_resolution 109 145 pass.set_resolution = fixed 146 }}} 147 148 === How to combine the `tracopt.ticket.commit_updater` with the testing workflow === 149 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. 151 152 By default it reacts on some keywords found in changeset message logs like ''close'', ''fix'' etc. and performs the corresponding workflow action. 153 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. 155 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. 157 158 == Example: Add simple optional generic review state == 159 160 Sometimes Trac is used in situations where "testing" can mean different things to different people so you may want to create an optional workflow state that is between the default workflow's `assigned` and `closed` states, but does not impose implementation-specific details. The only new state you need to add for this is a `reviewing` state. A ticket may then be "submitted for review" from any state that it can be reassigned. If a review passes, you can re-use the `resolve` action to close the ticket, and if it fails you can re-use the `reassign` action to push it back into the normal workflow. 161 162 The new `reviewing` state along with its associated `review` action looks like this: 163 164 {{{ 165 review = new,assigned,reopened -> reviewing 166 review.operations = set_owner 167 review.permissions = TICKET_MODIFY 168 }}} 169 170 Then, to integrate this with the default Trac 0.11 workflow, you also need to add the `reviewing` state to the `accept` and `resolve` actions, like so: 171 172 {{{ 173 accept = new,reviewing -> assigned 174 […] 175 resolve = new,assigned,reopened,reviewing -> closed 176 }}} 177 178 Optionally, you can also add a new action that allows you to change the ticket's owner without moving the ticket out of the `reviewing` state. This enables you to reassign review work without pushing the ticket back to the `new` status. 179 180 {{{ 181 reassign_reviewing = reviewing -> * 182 reassign_reviewing.name = reassign review 183 reassign_reviewing.operations = set_owner 184 reassign_reviewing.permissions = TICKET_MODIFY 185 }}} 186 187 The full `[ticket-workflow]` configuration will thus look like this: 188 189 {{{ 190 [ticket-workflow] 191 accept = new,reviewing -> assigned 192 accept.operations = set_owner_to_self 193 accept.permissions = TICKET_MODIFY 194 leave = * -> * 195 leave.default = 1 196 leave.operations = leave_status 197 reassign = new,assigned,accepted,reopened -> assigned 198 reassign.operations = set_owner 199 reassign.permissions = TICKET_MODIFY 200 reopen = closed -> reopened 201 reopen.operations = del_resolution 202 reopen.permissions = TICKET_CREATE 203 resolve = new,assigned,reopened,reviewing -> closed 204 resolve.operations = set_resolution 205 resolve.permissions = TICKET_MODIFY 206 review = new,assigned,reopened -> reviewing 207 review.operations = set_owner 208 review.permissions = TICKET_MODIFY 209 reassign_reviewing = reviewing -> * 210 reassign_reviewing.operations = set_owner 211 reassign_reviewing.name = reassign review 212 reassign_reviewing.permissions = TICKET_MODIFY 110 213 }}} 111 214 … … 132 235 But if even that is not enough, you can disable the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it. 133 236 237 == Adding Workflow States to Milestone Progress Bars == 238 239 If you add additional states to your workflow, you may want to customize your milestone progress bars as well. See [TracIni#milestone-groups-section TracIni]. 240 134 241 == some ideas for next steps == 135 242 136 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. 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. 137 244 138 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. … … 142 249 * '''postops''': automatic, when leaving the state/activity 143 250 * '''actions''': can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows. 144 This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement. 251 ''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.'' 145 252 146 253 * operations could be anything: sum up the time used for the activity, or just write some statistical fields like 147 A workflow plugin can add an arbitrary workflow operation, so this is already possible. 254 ''A workflow plugin can add an arbitrary workflow operation, so this is already possible.'' 148 255 149 256 * set_actor should be an operation allowing to set the owner, e.g. as a "preop": 150 257 * either to a role, a person 151 258 * entered fix at define time, or at run time, e.g. out of a field, or select. 152 This is either duplicating the existing `set_owner` operation, or needs to be clarified. 259 ''This is either duplicating the existing `set_owner` operation, or needs to be clarified.'' 153 260 154 261 * Actions should be selectable based on the ticket type (different Workflows for different tickets) 155 This is becoming a frequent request, with clear usecases. The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point. 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.
