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 = bug with a status = fixed will have a link in the action bar called Close defect. Clicking this link will change the card's 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 as 'Complete', alongside simply setting the status to completed 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 actioned. 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 set up.

You can 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.

It is useful to capture values like Date completed on, or Analysis complete on for reporting purposes, but these values don't have to be shown on the card and you might choose to 'Hide' them. These hidden properties can be updated/captured automatically using transitions

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 or only specific team members. When you select Only selected team members, Mingle displays a list of all team members and you can select the checkbox next to their name to make the transition visible to these people only.

This is useful if you want only certain people performing specific functions. For example, you may decide that only a tester should be able to close defects, so you would make the Close defect transition available only to team members who are testers. 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

• About card properties
• Customizing projects