Changes between Version 11 and Version 12 of TracWorkflow

Timestamp:

Sep 10, 2020, 8:03:01 PM (4 years ago)

Author:

trac

Comment:

--

TracWorkflow

@@ -7 +7 @@
 == 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:branches/1.2-stable/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 +41 @@
 == Additional Ticket Workflows
 
-There are example workflows provided in the Trac source tree, see [trac:source:branches/1.2-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. 
+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 +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.
 
-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`:
 
@@ -69 +69 @@
  - ''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.
@@ -101 +101 @@
 leave.default = 1
 }}}
+
+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.
@@ -237 +239 @@
 == 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:branches/1.2-stable/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 +249 @@
 == 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.