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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

• Create card transitions
• Modify or delete card transitions
• Apply transition only properties
• Automate transitions on the grid view

• Card Transitions page
• About card properties
• Generating transitions
• User groups
• Customizing projects