Resolution field Not updated when closing ticket

Summary

When working with the Resolution Field sometimes you may see that the Resolution is not shown as 'Updated" in the Issue History when Closing a Ticket. This can cause a multitude of issues because the Issue Event is required to register or formally update the field value. This can have a cascading effect with:

• SLAs continuing to run because the Resolution: Set Finish/Pause SLA Condition is not "met"

  • This causes issues with:

    • Reports

    • Dashboards

    • SLA Metrics on Jira Issues

    • Issue Filters on SLAs

But what causes this to happen? How can it be prevented?

Diagnosis

On the affected issue workflow, the Resolution is the Last Post Function Event in the list of Post Functions on the Transition to the Done Status Category Type (any Done/Green Status that closes the Issue and sets the Resolution).

Cause

Since the Resolution is the Last Post Function Event in the list of Post Functions and after the Generic Event is triggered, the Resolution being set on the Jira Issue is not being added to the Issue History. This is because the Generic Event is the event that triggers the Issue History to be updated on the Jira Issue. Since it is fired before the Resolution is Set, the Issue History is not updated, causing the various issues mentioned earlier.

Solution

To solve this, simply move the Resolution Post Function up above the Generic Event in the list of Post Functions. This will ensure the Resolution is Set and the Post Function Events are included in the Generic Event that adds the Resolution to the Issue History.

Supporting Documentation:

• Best practices on using the "Resolution" field

• Essential Post Functions

  • Every Jira transition has the following essential post functions, which are performed in this order:

    1. Set issue status to the linked status of the destination workflow status.

    2. Add a comment to an issue if one is entered during a transition.

    3. Update change history for an issue and store the issue in the database.

    4. Re-index an issue to keep indexes in sync with the database.

    5. Fire a Generic event that can be processed by the listeners.