Changes between Version 69 and Version 70 of TracWorkflow
- Timestamp:
- Apr 27, 2017, 2:16:54 AM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracWorkflow
v69 v70 7 7 == The Default Ticket Workflow 8 8 9 When a new environment is created, a default workflow is configured in your trac.ini. This workflow is the basic workflow, suchas specified in [trac:source:/trunk/trac/ticket/workflows/basic-workflow.ini basic-workflow.ini]:9 When a new environment is created, a default workflow is configured in your trac.ini. This workflow is the basic workflow, as specified in [trac:source:/trunk/trac/ticket/workflows/basic-workflow.ini basic-workflow.ini]: 10 10 11 11 {{{#!Workflow width=700 height=300 … … 49 49 '''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. 50 50 51 Create a `[ticket-workflow]` section in `trac.ini`. 52 Within this section, each entry is an action that may be taken on a ticket. 51 In the `[ticket-workflow]` section of `trac.ini`, each entry is an action that may be taken on a ticket. 53 52 For example, consider the `accept` action from `simple-workflow.ini`: 54 53 … … 60 59 61 60 The first line in this example defines the `accept` action, along with the states the action is valid in (`new` and `accepted`), and the new state of the ticket when the action is taken (`accepted`). 62 The `accept.permissions` line specifies whatpermissions the user must have to use this action.63 The `accept.operations` line specifies changes that will be made to the ticket in addition to the status change when th isaction is taken. In this case, when a user clicks on `accept`, the ticket owner field is updated to the logged in user. Multiple operations may be specified in a comma separated list.61 The `accept.permissions` line specifies the permissions the user must have to use this action. 62 The `accept.operations` line specifies changes that will be made to the ticket in addition to the status change when the action is taken. In this case, when a user clicks on `accept`, the ticket owner field is updated to the logged in user. Multiple operations may be specified in a comma separated list. 64 63 65 64 The available operations are: 66 - **del_owner** -- Clear the owner field.65 - **del_owner** -- Clears the owner field. 67 66 - **set_owner** -- Sets the owner to the selected or entered owner. Defaults to the current user. When `[ticket] restrict_owner = true`, the select will be populated with users that have `TICKET_MODIFY` permission and an authenticated session. 68 - ''actionname''`.set_owner` may optionally be set toa comma delimited list of users that will be used to populate the select, or a single user. Groups and permissions may also be included in the list //(Since 1.1.3)//. When groups or permissions are specified the select is populated with all members of the group or all users that possess the permission.67 - ''actionname''`.set_owner` may optionally specify a comma delimited list of users that will be used to populate the select, or a single user. Groups and permissions may also be included in the list //(Since 1.1.3)//. When groups or permissions are specified the select is populated with all members of the group or all users that possess the permission. 69 68 - **set_owner_to_self** -- Sets the owner to the logged in user. 70 69 - **may_set_owner** -- Sets the owner to the selected or entered owner. Defaults to the existing owner. //(Since 1.1.2)//. … … 83 82 '''Note:''' Specifying conflicting operations, such as `set_owner` and `del_owner`, has unspecified results. 84 83 85 In this example, we see the `.label` attribute used. The action here is `resolve_accepted`, but it will be presented to the user as `resolve`: 84 The example that follows demonstrates the `.label` attribute. The action here is `resolve_accepted`, but it will be presented to the user as `resolve`. 86 85 87 86 {{{#!ini … … 92 91 }}} 93 92 94 In this example, we see the `.label` attribute used. The action here is `resolve_accepted`, but it will be presented to the user as `resolve`.The `.label` attribute is new in Trac 1.1.3 and is functionally the same as the `.name` attribute, which is now deprecated. If neither `.label` or `.name` is specified, the action will be presented to the user as //resolve accepted//, the underscores having been replaced by whitespace (//Since 1.1.3//).93 The `.label` attribute is new in Trac 1.1.3 and is functionally the same as the `.name` attribute, which is now deprecated. If neither `.label` or `.name` is specified, the action will be presented to the user as //resolve accepted//, the underscores having been replaced by whitespace (//Since 1.1.3//). 95 94 96 95 For actions that should be available in all states, `*` may be used in place of the state. The obvious example is the `leave` action: … … 148 147 149 148 {{{#!sh 150 cd /var/local/trac_devel/contrib/workflow/ 151 sudo ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini 152 }}} 153 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. 154 155 After you have changed a workflow, you need to restart your webserver for the changes to take effect. 149 $ cd /var/local/trac_devel/contrib/workflow/ 150 $ ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini 151 }}} 152 The script outputs `trac.pdf` in the same directory as the `trac.ini` file. 156 153 157 154 == Example: Adding optional Testing with Workflow 158 155 159 By adding the following to your [ticket-workflow] section of trac.ini you get optional testing. When the ticket has status `new`, `accepted` or `needs_work`, you can choose to submit it for testing. When it's in the testing status the user gets the option to reject it and send it back to `needs_work`, or pass the testing and send it along to `closed`. If they accept it, then it is automatically marked as `closed` and the resolution is set to `fixed`. Since all the old work flow remains, a ticket can skip this entire section.156 The following adds a `testing` action. When the ticket has status `new`, `accepted` or `needs_work`, you can choose to submit it for testing. When it's in the testing status the user gets the option to reject it and send it back to `needs_work`, or pass the testing and send it along to `closed`. If they accept it, then it is automatically marked as `closed` and the resolution is set to `fixed`. Since all the old work flow remains, a ticket can skip this entire section. 160 157 161 158 {{{#!ini … … 212 209 }}} 213 210 214 The full `[ticket-workflow]` configuration will thus look like this:211 The full `[ticket-workflow]` configuration will be: 215 212 216 213 {{{#!ini … … 266 263 If the customizations above do not meet your needs, you can extend the workflow with plugins. 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 [trac:source:trunk/sample-plugins/workflow sample-plugins/workflow] for a few examples to get started. 267 264 268 But if even that is not enough, you can disable the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it. 265 But if even that is not enough, you can disable the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it. See also the [https://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin], which provides additional operations. 269 266 270 267 == Adding Workflow States to Milestone Progress Bars 271 268 272 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].269 If you add additional states to your workflow, you may want to customize your milestone progress bars as well. See the [TracIni#milestone-groups-section "[milestone-groups]"] section. 273 270 274 271 == Ideas for next steps 275 272 276 Enhancement ideas for the workflow system should be filed as enhancement tickets against the [trac:query:?status=assigned&status=new&status=reopened&keywords=~workflow&component=ticket+system ticket system] component. You can also document ideas on the [trac:TracIdeas/TracWorkflow TracIdeas/TracWorkflow] page. Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations.273 Enhancement ideas for the workflow system should be filed as enhancement tickets against the [trac:query:?status=assigned&status=new&status=reopened&keywords=~workflow&component=ticket+system ticket system] component. You can also document ideas on the [trac:TracIdeas/TracWorkflow TracIdeas/TracWorkflow] page.