Changes between Version 2 and Version 3 of TracWorkflow

Timestamp:

Sep 13, 2025, 3:01:44 PM (4 months ago)

Author:

trac

Comment:

--

TracWorkflow

@@ -3 +3 @@
 [[PageOutline(2-5,Contents,pullout)]]
 [[TracGuideToc]]
-The Trac ticket system provides a configurable workflow.
+
+The Trac ticket system provides a configurable workflow on how tickets are treated.
 
 == The Default Ticket Workflow
 
-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]:
+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:branches/1.4-stable/trac/ticket/workflows/basic-workflow.ini basic-workflow.ini]:
 
 {{{#!Workflow width=700 height=300
@@ -41 +42 @@
 == Additional Ticket Workflows
 
-There are example workflows provided in the Trac source tree, see [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. 
+There are example workflows provided in the Trac source tree, see [trac:source:branches/1.4-stable/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.
 
 Here are some [trac:WorkFlow/Examples diagrams] of the above examples.
@@ -49 +50 @@
 '''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.
 
-In the `[ticket-workflow]` section of `trac.ini`, each entry is an action that may be taken on a ticket. 
+In the `[ticket-workflow]` section of `trac.ini`, each entry is an action that may be taken on a ticket.
 For example, consider the `accept` action from `simple-workflow.ini`:
 
@@ -62 +63 @@
 The `accept.permissions` line specifies the permissions the user must have to use this action. [trac:ExtraPermissionsProvider] can define new permissions to be used here.
 
-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.
+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.
 
 The available operations are:
@@ -69 +70 @@
  - ''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.
 - **set_owner_to_self** -- Sets the owner to the logged in user.
-- **may_set_owner** -- Sets the owner to the selected or entered owner. Defaults to the existing owner. //(Since 1.1.2)//. 
+- **may_set_owner** -- Sets the owner to the selected or entered owner. Defaults to the existing owner. //(Since 1.1.2)//.
 - **del_resolution** -- Clears the resolution field.
 - **set_resolution** -- Sets the resolution to the selected value.
- - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example:
+ - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. The resolution(s) specified in this attribute must be defined in the database. Example:
  {{{#!ini
 resolve_new = new -> closed
@@ -102 +103 @@
 }}}
 
+The transition to `*` (`-> *`) means the workflow operation determines the next status. The only configurable ticket workflow operation that determines the next status is `leave_status`. However, another workflow controller can operate on an action with new status `*` and determine the next status.
+
 This also shows the use of the `.default` attribute. This value is expected to be an integer, and the order in which the actions are displayed is determined by this value. The action with the highest `.default` value is listed first, and is selected by default. The rest of the actions are listed in order of decreasing `.default` values.
 If not specified for an action, `.default` is 0. The value may be negative.
@@ -146 +149 @@
 Workflows can be visualized by rendering them on the wiki using the [WikiMacros#Workflow-macro Workflow macro].
 
-Workflows can also be visualized using the `contrib/workflow/workflow_parser.py` script. The script outputs `.dot` files that [http://www.graphviz.org GraphViz] understands. The script can be used as follows (your install path may be different):
+Workflows can also be visualized using the `contrib/workflow/workflow_parser.py` script. The script outputs `.dot` files that [https://www.graphviz.org GraphViz] understands. The script can be used as follows (your install path may be different):
 
 {{{#!sh
@@ -156 +159 @@
 == Example: Adding optional Testing with Workflow
 
-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.
+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 workflow remains, a ticket can skip this entire section.
 
 {{{#!ini
@@ -197 +200 @@
 reassign_reviewing = reviewing -> *
 reassign_reviewing.label = reassign review
-reassign_reviewing.operations = set_owner
+reassign_reviewing.operations = set_owner, leave_status
 reassign_reviewing.permissions = TICKET_MODIFY
 }}}
@@ -230 +233 @@
 review.permissions = TICKET_MODIFY
 reassign_reviewing = reviewing -> *
-reassign_reviewing.operations = set_owner
+reassign_reviewing.operations = set_owner, leave_status
 reassign_reviewing.label = reassign review
 reassign_reviewing.permissions = TICKET_MODIFY
@@ -237 +240 @@
 == Advanced Ticket Workflow Customization
 
-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.
+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:branches/1.4-stable/sample-plugins/workflow sample-plugins/workflow] for a few examples to get started.
 
 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.
@@ -247 +250 @@
 == Ideas for next steps
 
-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. 
+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.