A project workflow can be configured in more detail, adding various constraints to the statuses and the transitions between statuses. Setting a configuration is optional. If no configuration is made, then any transition to any status will be possible.


Prerequisites


Select the workflow and click Edit config to open the Edit XML dialog.

Example Configuration

Below is a simple workflow definition which limits the status transition options using <NextStatuses>.

<Workflow initialStatus="New">
    <Status name="New">
        <NextStatuses>
            <NextStatus name="In Progress"/>
        </NextStatuses>
    </Status>
    <Status name="In Progress">
        <NextStatuses>
            <NextStatus name="Test"/>
            <NextStatus name="Done"/>
        </NextStatuses>
    </Status>
    <Status name="Test">
        <NextStatuses>
            <NextStatus name="In Progress"/>
            <NextStatus name="Done"/>
        </NextStatuses>
    </Status>
    <Status name="Done">
        <NextStatuses>
            <NextStatus name="In Progress"/>
            <NextStatus name="Test"/>
        </NextStatuses>
    </Status>
</Workflow>


Explanation of the Configuration Elements

<Workflow> is mandatory, and can include one workflow configuration.

  • It includes one required initialStatus attribute which identifies the initial status of any issue according to the workflow. 

The <Workflow> element contains optional <Status> elements.


<Status> defines one status in the workflow process. If a specific status is not listed as a <Status> element, then no transitions to/from that status will be possible.

  • Each Status has one required name attribute, and the value must correspond to a status defined in the workflow. 


Optional Constraints on Status

Each <Status> element can contain any of the following optional elements, each defining invariant conditions of a status, and the possible transitions from the status:

  • The <NextStatuses> tag contains one or more <NextStatus> elements, each defining a valid next status for the issues following the given workflow. If a <Status> has no <NextStatus> element, then no transitions from that status will be possible. Note: Transitions from a "Closed" status are not prevented by default. If you want to prevent them, you will need to add a configuration to specify the allowed next statuses.
    • NextStatus has one required name attribute identifies a target status for the transition. The name value must be a valid status in the workflow.

In the simple example shown above, issues in status "Test" can move to either "In progress" or "Done". They cannot be moved from "Test" to "New". 

  • The <Preconditions> element can contain separate <Precondition> elements, each defining a condition that must be fulfilled for an issue to transition to  the status. 
    • The test attribute defines a SystemWeaver Path expression that must evaluate to true. 
    • The message attribute defines an optional message to the user, should the condition not be fulfilled.

In the below example, an issue must be assigned to someone to be able to be moved to "In progress". When "Assigned to" is left blank, users receive a message.

...
  <Status name="New">
    <NextStatuses>
      <NextStatus name="In Progress"/>
    </NextStatuses>
  </Status>

  <Status name="In Progress">
    <Preconditions>
      <Precondition test="AssignedTo.Name != ''" message="Not assigned to anyone."/>
    </Preconditions>
    <NextStatuses>
      <NextStatus name="Done"/>
    </NextStatuses>
  </Status>
...
  • The <Restrictions> element allows you to make all, or specific, elements of issues as read-only in all or one or more statuses. To apply to a specific Status, place the <Restrictions> within the specific <Status>. To apply to all statuses, place the <Restrictions> within an <All> tag within <Workflow>.
    • The field attribute identifies the element to be restricted. For a complete list of the fields that can be restricted, see Restrictions in the swExplorer Reference Manual in the application Help.
    • The test attribute defines a SystemWeaver Path expression that must evaluate to true. Restrictions are applied by project and effect all members of the project unless specifically configured otherwise.  

See How to Make Issues Read-Only and How to Restrict Issue Deletion for examples.

  • <AssignedTo> can be used for auto-assignment of an issue upon moving to  the target status based on a defined criteria. It is possible to have multiple AssignedTo tags, in which case the first to validate will apply. AssignedTo has two attributes: 
    • The user attribute is required, and sets the assigned-to criteria, e.g., names a specific user, points to a User (single) attribute found in the issue, etc.
    • The test attribute is optional, and defines a SystemWeaver Path expression that must evaluate to true. 

In the below example, when issues transition to the "Done" status, they are assigned to user "john.doe" if the attribute with SID=RENO is set to "Review", and assigned to user "tracy.klein" if the attribute is set to "Needed". 

...
<Status name="Done">
  <AssignedTo user="User('john.doe')" test="@RENO = 'Review'"/>
  <AssignedTo user="User('tracy.klein')" test="@RENO = 'Needed'"/>
  <NextStatuses>
   <NextStatus name="In progress"/>
  </NextStatuses>
 </Status>
...
  • <Request> can be used to add an approval step(s) called Request for status change to a workflow. 
  • <AutoRequest> can be used to transition issues automatically to a next Request in the workflow, 

See Configuring Request for Status Change for more details on how to configure Request for status change and AutoRequest,

Context Visualizer

You can view a graphical visualization of your workflow by selecting the entire configuration, and then selecting Show context visualizer in the right-click context menu. The illustration is a useful tool for project administrators. 




Once you are satisfied with your workflow configuration, click OK to save. 

What's Next?

If you haven't already created the Issue Types in your project, see Creating Issue Types.