Summary

In the Kanban boards, a strike-through appears on the issues if the issue is moved to a resolved state with the resolution set as part of the workflow transitions and then reverted to a previous state without using a 'clear resolution' post-function.

Sometimes this leads to confusion to the end users who still see the strike-through on the issues in boards even when 'Resolution' field is set to 'Unresolved' manually or using alternate methods like CSV import.

Environment

Jira Server 8.X and 9.X versions.

Diagnosis

• The strike-out appears when an issue is seen as "resolved" by Jira.

• This is done by looking at the 'Resolution' field. If there is any value in this field, Jira assumes the issue as resolved. It is only 'unresolved' when the field is empty (null in the database).
  Note that Jira displays "Unresolved" in the field display when the field is empty.

• We need to clear out the value present in this field and only way to do that (without code) is to push the issue through a transition that has the standard "clear resolution field" post-function.
  These are usually placed on transitions that are "re-open" type but not limited to.

Cause

Whenever an issue is moved to a completed/closed status by setting the 'Resolution' as part of the workflow transition, it stores the value inside the database 'jiraissue' table for field 'Resolution'. This can be validated by running the queries specified in the last section of the article (Queries used to validate and address the issue through database approach) and noting down the issue id of the impacted issue.

When the issue is re-opened or moved back to previous state using a transition which doesn't use 'Clear Resolution' post function, then 'Resolution' field will not be cleared and hence Jira still assumes this issue as resolved and a strike-through appears on the issue displayed as part of the board. This should be cleared in order to resolve the issue.

Solution

There are 2 ways to address the issue 1) Standard post-function based approach and 2) Database approach.
 Make sure to take appropriate backups in either case and test in a lower environment to confirm the solution and then move with production changes.

• The most preferred and standard approach being the post-function based approach which doesn't need instance restart.
  
  
  • We need use the 'Clear Resolution' post-function in any of the next status transitions and publish the workflow.
  • When we say 'Clear Resolution' post-function it means use the post-function to 'Update the Field' and set the 'Resolution' field to 'None' as discussed during the discussion.
  • The impacted issue needs to pass through this transition to get the 'strike-through' is cleared.
  • Once the changes are made and issue is resolved, revert the workflow changes and publish it (If required, we can still continue with changes).
  • In below screenshots, we have used clear resolution field postfunction in 'In Progress' transition and we could see strike-through gets removed as the issues pass through this transition.
    
    
• Second approach is to clear the database entry for the impacted issue from 'jiraissue' table and 'Resolution' field.

• • Take the database (jiraissue) table backup before making any changes the database.
  • Identify the issue id from the database entries using project-key, issue number, you can use the queries shared above for this purpose.
  • Update the 'Resolution' field for this issue and set it to 'NULL' which is ideal condition when issue is created.
  • Once this is done, navigate to the issue and confirm it's reflecting 'Unresolved' in the 'Resolution' field. Now transition the issue to the next status to refresh the board cache and validate to confirm the problem is resolved.

Queries used to validate and address the issue through database approach

Whenever an issue is moved to a completed/closed status by setting the 'Resolution' as part of the workflow transition, it stores the value inside the database 'jiraissue' table for field 'Resolution'. This can be validated by running below query and noting down the issue id for validation in next query.

• Query1: To get the issue id and project details of the impacted issue.
• Query2: To get all the fields for specific issue and validation of resolution field having value.
• Query3: To clear the resolution field.

-- SELECT CONCAT(jp.pkey, '-', ji.issuenum) AS issuekey, ji.*
FROM project jp
JOIN jiraissue ji ON jp.id = ji.project
WHERE CONCAT(jp.pkey, '-', ji.issuenum) = '<impacted jira issue>';

-- SELECT * FROM jiraissue WHERE id = <id value returned from above query>; 

-- UPDATE jiraissue SET resolution='NULL' WHERE id=<id value returned from above query>;