Issues transitioning to the wrong status in Jira Data Center
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Some issues can't be transitioned to a specific status. When this is attempted, the issue consistently transitions to a different status instead.
For example, whenever a certain issue is transitioned to the Done status, it might instead transition to the In Review status. Further attempts to transition it to Done would only result in it staying in the In Review status.
Diagnosis
Jira logs errors similar to the following:
2022-11-10 00:00:00,000+0000 http-nio-8080-exec-3147 url: /secure/AjaxIssueAction!default.jspa; user: username ERROR username 123x45678901x2 sessionid 1.2.3.4 /secure/AjaxIssueAction!default.jspa [c.a.jira.workflow.IssueWorkflowManagerImpl] State of issue [TEST-101] has an action [id=100] which cannot be found in the workflow descriptor
Confirmation can be obtained by querying the Jira database for the name of the issue's workflow. For instance, to check the workflow name for the issue TEST-101, run the following SQL query:
SELECT name FROM os_wfentry WHERE id=(SELECT workflow_id FROM jiraissue WHERE project=(SELECT id FROM project WHERE pkey='TEST') AND issuenum=101);Then go to the project settings of the issue's parent project and compare the workflow assigned to the issue's type with the workflow obtained via the SQL query above. If the workflow names don't match, then the issue is affected by workflow inconsistencies.
Cause
This problem is caused when an issue has a workflow assigned to it in the os_wfentry database table which does not match the workflow assigned to its issue type in the parent project.
The exact symptoms can vary depending on how much the two workflows differ. If the two workflows are identical then no impact will be observed. If the two workflows differ completely then the transition buttons may disappear entirely. However, if the two workflows are mostly but not entirely similar, the discrepancy may cause the issue to transition to a status other than the expected one.
Solution
Several options exist for resolving the workflow inconsistency, each with different advantages and disadvantages.
As with all recommendations made by Atlassian Support, please follow best practices for Change Management and test and validate these settings in a Test/Development and Staging environment prior to rolling any changes into a Production environment.
Solution 1: Clone the issue then delete the original
This is a three-step process:
Clone the affected issue.
Confirm that the clone has all the necessary information and works properly.
Delete the original issue.
The advantage is that the original issue remains unchanged, allowing for confirmation that the new cloned issue works and has all the necessary information before the original is deleted.
The disadvantages are:
Certain types of information, such as comments, time tracking, issue history and links to Confluence pages, are not copied over in the cloning process and must be manually added later.
External links to the original issue will break when it is deleted, unless the links are updated manually.
Solution 2: Change the issue's type then change it back
This is a two-step process:
Move the Issue Type of the impacted issue to a different Issue Type with a different workflow.
Move it back to its original value.
The advantage is that the issue's comments, time tracking, issue history and external links will all be preserved.
Its disadvantage is that if the new issue type's fields are different, some of the issue's fields may be cleared and need to be re-entered.
Solution 3: Change the workflow for the issue type and then change it back
This is a three-step process:
Copy the affected workflow.
Associate the copied workflow with the affected issue's issue type.
Associate the affected issue types back to the original workflow (optional).
The advantage is that if a large number of issues are affected this will be more efficient than fixing them one by one.
The disadvantage is that it updates all issues of that type in the project, which may not be desirable if only a few issues are affected.
Was this helpful?