Card transitions give your team a shortcut for completing common actions in Mingle, such as closing a bug or marking a user story as complete. Card transitions are context sensitive. They are presented to the user only when appropriate to the current state of the card they are working with. Card transitions allow you to define a workflow for your project. You can use transitions to assign work to various team members at different stages of the project lifecycle. Essentially you can use transitions to automate any set of property changes to a card that should be performed in one go.
You must setup card properties before you can create card transitions.
Context sensitive workflow actions
Card transitions appear as links in the action bar area on cards that match the card properties you specify in the card transition. For example, in the Close defect transition below:
Any card that is of Type is Defect with a Defect Status is Fixed will have a link in the action bar called Close defect. Clicking this link will change the card's defect status to closed and remove the card's previous owner.
Transitions which do not prompt for user input can also be used in bulk edit mode in list views.
A transition will prompt for user input if any property is set to the special value (user input - required), (user input - optional) or if the Require team members to add a comment .. checkbox is ticked.
Automate common tasks using Transitions
You can use transitions to automate common or repetitive tasks, e.g.
When marking a story 'Complete', in addition to setting the status value, you might want to gather details like:
- Who closed the story
- When it was closed
- What the final amount of effort involved was
This data collection can be automated so that a user only needs a single click to collect and set the values.
Prompt the user to manually select values for properties
You can ensure that values are provided for specific properties by using the special values (user input - required) or (user input - optional). When a property is set to (user input - required) then the user will be prompted to select an appropriate value for that property when the transition is invoked. They will not be able to complete the transition until they select a value. If the property is set to (user input - optional) then the user will be prompted to select an appropriate value but they can complete the transition without selecting a value for this property as it is not mandatory for the transition.
Capture values like development effort by prompting for a value when a developer uses the transition 'dev complete'. You could also ask a member to set a due date for himself when signing up for a card.
Control changes to property values
You can control changes to property values by marking those properties as transition only. This means the value of that property can only be set via a transition, and cannot be edited directly. Because you can control when a particular transition will be made available to the user, you can ensure that cards move through a prescribed workflow. So for example by making status a transition only field, and specifying that the bug card must have status set to 'fixed' for the Close defect transition, you ensure that bugs can only be closed if they have been fixed.
You would also have to create transitions for the other allowable state changes for the bug status property. Examples might include:
- Assign defect - where a defect is 'open' or 'new', which could prompt for a team member, and change the status to 'assigned'
- Reject defect - where a defect is 'open' or 'new', which could prompt for a comment (to collect the reason the defect was rejected) and change the status to 'rejected'
- Reopen defect - which would allow a defect with status = 'closed' to be re-opened, this might prompt for a comment and set the status to 'open'
- Mark defect fixed - where a defect is assigned, which could set the status to 'fixed'
Of course, there are many possible work flows for defect management, but these examples serve to illustrate the sort of state transitions you might want to setup.
Use project variables to change property values
You can make changes to property values by using project variables. As example below, the project variable 'Current Iteration' is set as a value of property 'Iteration - Analysis Complete'. The assigned value for (Current Iteration) will be used to set this property value when this transition is invoked.
Change for any set property to a specified property using (set)
You can create transitions that will apply to any card that has a property value set (i.e. value is not (not set)) by setting the property value to (set) in the transition prerequisites. This type of transition is useful if you want to ensure the property has a value but you don't care what the value is. For example if you want all stories to have a priority before they are added to an iteration etc... The (set) value is also useful if you want to allow the same action to happen on cards that have any value but (not set), for example if you want to be able to set any story that is somewhere in the development process to be "blocked" you can say where status is (set) to do this.
Prompt for explanatory comments on important actions
When a team member is 'soft deleting' a card (setting the status property to deleted) or removing a story from scope, you can setup transitions to ensure a comment is entered explaining why this action was performed.
Hidden card properties
The Card transitions page indicates hidden properties with a colored background.
In some cases you may have hidden card properties which are only used in reporting and do not need to be set directly by users. Setting these hidden properties is a common use for a transition. One common example is to create date properties to track when a card enters specific states. The transitions which change the state of the card set the current date into the corresponding date property at the time the state changes. e.g. "Date Development Started" might get set to (current date) when a developer begins work on a card, then "Date Dev Done" set once it's ready for testing, then "Date Signed Off" set when the card is signed off. If a card property is hidden, this transition link will still display for cards that meet the card property criteria. The user will still be able to see that a hidden property has been updated by a transition if they look at the history for that card.
Update hidden 'reporting' properties automatically
It is useful to capture values like 'Date completed on' or 'Analysis completed on' for reporting purposes, but these values do not have to be shown on the card and you might choose to 'Hide' them. These hidden properties can be updated/captured automatically using transitions.
Transitions for specific team members
When you create transitions, you can make them available for all team members, only specific team members, or only team members who belong to specific user groups.
- If you don't need to restrict who can use a transition, select All team members.
- Only selected team members restricts usage of a transition to specific team members that you select. This choice is less adaptive to changes in team structure than Only team members of selected user groups, but may be appropriate if you have not created user groups for your project, or you need more strict access control.
- Choose Only team members of selected user groups if you only want team members that belong to specific user groups to use the transition. For example, you may decide that only team members in the "Testers" user group can close defects, so you would make the "Close defect" transition available only to team members in that user group. As team members join the "Testers" user group, they would automatically have access to the "Close defect" transition. Likewise, if a team member leaves the "Testers" user group, they will no longer have access to the transition. In this way, using Only team members of selected user groups to restrict access to transitions is more flexible and maintainable than Only selected team members.
To prevent direct access to the properties set in the transition, you should also mark them as transition only.
Removing cards from a tree
As well as updating card property values, transitions can also be used to remove cards from trees. There are a number of options when removing cards from tree using transitions just as there are when removing them manually from the tree. You can remove just one card using (remove card from this tree) or remove the card and any children it has using (remove card and its children from this tree).
If the card is the lowest level of the tree then only the (remove card from this tree) option will be available.
When removing a card from a tree any tree relationship properties will be set to (not set) automatically.
Just like other transitions you can set other properties at the same time as removing cards from a tree. This is useful if you want to remove stories from scope and set some reporting properties, such as date removed from scope, at the same time.