Resolved, Resolution and Resolution Date

This week's jiradev post is one result of the Second Atlassian Doc Sprint last week. For two days over thirty people from many different groups in Atlassian and others from all over the world "scratched their itches" to add and update the Atlassian documentation. I'm looking forward to the next one sometime in 2011.

~Matt

One area that sometimes confuses JIRA users and administrators is the difference between Resolved and Resolution. Many of the standard JIRA reporting gadgets expect the Resolution field to be set as described below or confusing results can occur.

Summary Resolved is one of the issue statuses in the default JIRA workflow. Resolution is a system field with values of Fixed, Not Fixed, etc. The Resolution field is usually set during transitions. The Resolution Date system field is the latest date that the Resolution field was set to a value.

Resolved

JIRA comes with a default workflow (Admin, Global Settings, Workflows) that has the following expected series of statuses for an issue:

Open to In Progress to Resolved to Closed

The idea is that a bug is created with a status of Open, and is then moved to In Progress and Resolved by the person who fixes it. The bug is then moved to Closed by someone who checks that it really was fixed. Resolved is just a name for an issue status - the status could as well be named "Believed Fixed" or "Ready for Testing".

The Resolved status has not connected directly with the Resolution field

Resolution

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

• "Closed and Fixed"
• "Closed and Won't Fix"
• "Closed because Duplicate"

The system field Resolution (Admin, Issue Settings, Resolutions) can be used to avoid this increase in the number of statuses. The default values of Fixed, Won't Fix, Duplicate, Incomplete and Cannot Reproduce cover many of the reasons a bug could be closed.

The intended use of Resolution is that when a bug is created the field is empty, with no value. This is shown in an issue as a value of "Unresolved". When an issue is moved to another state such as Resolved or Closed, the Resolve Issue Screen is shown during the transition and this screen has the Resolution field on it. So a bug can have its Resolution set to Fixed while it moving to the Resolved state.

Tip: in a standard JIRA installation, 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.

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.

The only way to remove the resolution from an issue in a standard JIRA installation is to Reopen an issue. You can add the Resolution field to the Default Screen to make it easier to change the value, but a transition is still required to reset the resolution to empty.

Also see How to Clear the Resolution Field

Resolution Date

The system custom field Resolution Date is the latest date for a given issue that any value was set in the system Resolution field. As noted in JRA-20286 with the default JIRA workflow, changing the issue status from Resolved to Closed will change the resolution date. The Resolution Date will only be empty if there is no value at all in the Resolution field.

The Resolution Date is confusingly named "Resolved" in the list of Issue Navigator columns.

Other Approaches

Many organizations using JIRA don't use the Resolution field because

• It's hard to reset the value to empty for "unresolved"
• It doesn't appear on standard screens, just during transitions
• It's hard to make it required on custom transition screens

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

Pros:
-Avoids confusion of the words Resolved and Resolution
-Works well with custom workflows since there is no need to add post-functions to set the system Resolution field for new transitions

Cons:
-The standard JIRA reporting gadgets are no longer as useful

Don't add a resolution named "Unresolved" to your the system Resolution field because the issue will still be treated as resolved by the standard JIRA gadgets, since it has a value.