Overview

One thing that sometimes confuses both JIRA users and administrators is the difference between the Resolved status and the Resolution field. This chapter clears up some of the confusion between these very similar-sounding terms. The differences are summarized at the end of this chapter (“Summary”).

Getting this right is important, because many of the standard JIRA reporting gadgets on dashboards expect the Resolution field to be set as expected—otherwise confusing results occur. For example, gadgets that refer to the date when issues were resolved use the Resolution Date field, which is in turn based on the Resolution field.

Resolved

JIRA comes with a default workflow (Administration→Issues→Workflows) named jira, shown later in Figure 5-1 and summarized below in Figure 2-1. This workflow has the following statuses for an issue, shown in the order they commonly occur.

Figure 2-1. Default JIRA workflow

The idea is that an issue (such as a bug) is created with a status of Open, and is then moved to In Progress and then Resolved by the person who fixes it. The bug is then moved to either Closed or Reopened by someone who checks whether it really was fixed or not. So Resolved is just a name for an issue status. The status could just as well have been named Believed Fixed or Ready for Testing.

Resolution

It’s generally a good idea to keep the number of statuses in your workflow as small as possible to make maintenance easier. It makes sense to avoid having lots of statuses with names like:

• Closed and Fixed
• Closed and Won’t Fix
• Closed Because It’s A Duplicate
• Closed Since…

The Resolution system field (Administration→Issues→Resolutions) can be used to avoid having lots of similar statuses. The default values for Resolution of Fixed, Won't Fix, Duplicate, Incomplete, Cannot Reproduce, Done and Won't Do cover many of the ways that an issue could be closed, and you can change this list if necessary. I find that a Complete resolution is often useful for generic tasks that are finished. Canceled is a gentler form of Won't Fix, but has spelling variants. Once the Resolution field in an issue contains any value at all, then links to that issue will have a line through them to indicate that the issue is resolved.

The intended use of the Resolution field is that when a bug is created, the field is empty, with no value at all. This is displayed in an issue as a value of Unresolved. When an issue is moved to a status such as Resolved or Closed, the Resolve Issue Screen is usually shown during the transition. This screen includes the Resolution field, ready for the user to set a value. A bug can have its Resolution set to Fixed while it is moving to the Resolved status, for example.

In the default JIRA workflow, the Resolve Issue Screen is the only screen where you can set the Resolution field for an issue, and this screen is only used for transitions to the Resolved and Closed statuses. In your own workflows you are responsible for making sure that the Resolution is set. Once the Resolution has been set, the issue is considered resolved by JIRA, even if the status of the issue is not the Resolved status but some other status defined by you (such as Deployed).

Another approach for cleaning up the results of an incorrect workflow and clearing the Resolution field in an issue is to create transitions back to the same status that have a post function to clear the Resolution. The ability to create transitions back to the same status is a non-obvious and useful ability for workflow designs.

One way to make sure you don’t have problems with the Resolution field and custom workflows is to create and save the JQL filter: status = Open and resolution is not empty order by created desc. This filter should always return zero issues. If there are Open issues with a resolution set being created, then you can look at a recent issue’s History tab and see where the resolution was not cleared. You can even set up a filter subscription to email any non-zero results to you.

A similarly useful query is status = Closed and resolution is empty order by created desc, which helps find workflows where the Close transition does not set the Resolution field. This filter should also return zero issues.

Resolution Date

The Resolution Date system field is the latest date that any value was set in the Resolution system field for that issue. The Resolution Date field will only be empty if there is no value at all in the Resolution field.

Other Approaches

Some organizations using JIRA don’t use the Resolution field for a number of reasons:

• It’s hard to reset the value to empty for unresolved issues.

• The resolution field doesn’t appear on standard screens, only during transitions.

• If the Resolution field is used on any custom transition screens, it’s hard to make the field not be required.

Instead, they base their reporting only on the name of the statuses in the workflows. They may also create their own custom Select List field named something like Our Resolution or Sub-status, with its own values such as Unresolved, Fixed, Won't Fix, Duplicate, Incomplete, and Cannot Reproduce.

The options for the Resolution field are defined for all JIRA projects and workflows. Sometimes you may want to restrict the resolutions used in a workflow. One way to do this is to use Workflow Properties. Another way to do this per issue type is to have a custom field with the Resolution options you want for each issue type, and then use a workflow post function to set the Resolution system field based on the value of the custom field (thanks to Joanna Thurmann for that idea).

A helpful approach to consider in custom workflows is creating a transition for each desired resolution, with a post function in each transition to set the resolution without using a screen. For example, there could be a transition from the current status to Closed named “Duplicate,” which automatically sets the resolution to Duplicate.

Summary

• Resolved is just the name of one of the issue statuses in the default JIRA workflow.

• Resolution is a system field with values of Fixed, Not Fixed, and so on. The Resolution field is only set during transitions.

• Don’t add the Resolution field to any screen except a transition screen.

• An unresolved issue is one with no value in the Resolution field.

• A resolved issue is one with any value in the Resolution field. Links to a resolved issue have a line through their displayed URL.

• The Resolution Date system field is the latest date that the Resolution field was changed to any value.

Further Reading

Some of the points in this chapter are mentioned briefly at https://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-OpenandClosedissuesdefined and in the comments there.

Clearing the Resolution field is covered at https://confluence.atlassian.com/display/JIRAKB/How+to+clear+the+resolution+field+when+the+issue+is+reopened.

The problem of the Resolution Date changing when an issue’s status is updated was described in the JIRA bug JRA-20286 and fixed in JIRA 4.3.1.

The Created vs Resolved Gadget described at http://confluence.atlassian.com/display/JIRA/Adding+the+Created+vs+Resolved+Gadget is a good example of where confusion can occur about what Resolved actually means—it’s the Resolution field, not the Resolved status.