Problems caused by importing and using a Workflow with missed status in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products 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
Please notice that this is not supported by Atlassian. It is provided for reference only and please make sure to make backups before applying the resolution below. Please refer Atlassian Support Offerings for more information.
When a Jira admin exports an XML from a Jira instance A and imports it to a target Jira instance B where some of the statuses are not available to be used in the imported workflow, Jira allows the import to proceed and marks the invalid status with a "?" at the workflow.
It may happen that a workflow scheme is created for this inconsistent workflow, and there is no validation to block this action (JRASERVER-43561 - Validate workflow integrity before allowing addition to workflow scheme).
If this workflow scheme is used by a project, it will cause multiple errors.
The goal of this document is to centralize information about the related bugs, feature requests, suggested workaround, and knowledge base articles related to this topic.
Environment
All Jira versions up to 8.12
Diagnosis
Steps to Reproduce:
1. On a staging instance of Jira create a new status;
2. Create a new workflow using the new status;
3. Export the workflow XML;
4. On production Jira import the workflow XML;
5. View the imported workflow using the "text" option. Observe that invalid status are marked with a "?" symbol;
6. Create a new workflow scheme and associate the invalid workflow imported;
7. Associate the new workflow scheme with a Project.
Problems observed:
Error 1: Transitions to the affected workflow fails with the workflow error "It seems that you have tried to perform an illegal workflow operation".
The following NullPointerException error can be observed at the log file:
1
2
3
4
5
6
7
8
9
10
11
12
13
2020-10-18 14:35:04,055-0300 http-nio-8080-exec-22 ERROR isabel 935x1314x1 1rtokm0 127.0.0.1 /secure/WorkflowUIDispatcher.jspa [c.a.jira.workflow.OSWorkflowManager] Caught exception while attempting to perform action 11 from workflow 10107 on issue 'SCRUM3-4'
java.lang.NullPointerException
at com.atlassian.jira.workflow.function.issue.UpdateIssueStatusFunction.execute(UpdateIssueStatusFunction.java:46)
at com.opensymphony.workflow.AbstractWorkflow.executeFunction(AbstractWorkflow.java:1014)
at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1407)
at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:557)
at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowActionInsideTxn(OSWorkflowManager.java:842)
at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowAction(OSWorkflowManager.java:799)
at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:514)
at com.atlassian.jira.web.action.workflow.SimpleWorkflowAction.doExecute(SimpleWorkflowAction.java:28)
... 1 filtered
at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:63)
[...]Error 2: Agile boards whose saved filter does not specify a project can no longer be configured
Conditions to reproduce this issue:
Board using a filter that does not specify a project created before the invalid workflow is used by a Project
Open the Board > reach the board > Configure option
Page does not load:
We can observe the following NullPointerException (NPE) error:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
/rest/greenhopper/1.0/rapidviewconfig/editmodel.json [web.rapid.view.RapidViewEditResource] Unable to complete GreenHopper REST method
java.lang.NullPointerException
at com.atlassian.greenhopper.web.rapid.view.ColumnEditRequest$StatusDetails.from(ColumnEditRequest.java:152)
at com.atlassian.greenhopper.web.rapid.view.ColumnEditHelper.asStatusEntry(ColumnEditHelper.java:444)
at com.atlassian.greenhopper.web.rapid.view.ColumnEditHelper.getUnmappedStatuses(ColumnEditHelper.java:343)
at com.atlassian.greenhopper.web.rapid.view.ColumnEditHelper.buildColumnStatusesModel(ColumnEditHelper.java:304)
at com.atlassian.greenhopper.web.rapid.view.ColumnEditHelper.buildColumnEditModel(ColumnEditHelper.java:199)
at com.atlassian.greenhopper.web.rapid.view.RapidViewEditHelper.getEditModel(RapidViewEditHelper.java:180)
at com.atlassian.greenhopper.web.rapid.view.RapidViewEditResource$9.call(RapidViewEditResource.java:243)
at com.atlassian.greenhopper.web.rapid.view.RapidViewEditResource$9.call(RapidViewEditResource.java:236)
at com.atlassian.greenhopper.web.util.RestCall.response(RestCall.java:42)
at com.atlassian.greenhopper.web.AbstractResource.createResponse(AbstractResource.java:111)
at com.atlassian.greenhopper.web.AbstractResource.response(AbstractResource.java:91)
at com.atlassian.greenhopper.web.rapid.view.RapidViewEditResource.getEditModel(RapidViewEditResource.java:235)Reference:
Error 3: Workflow scheme edition threws a NPE exception
Conditions to reproduce this issue:
At the Admin > Issues > Workflow scheme, edit the invalid workflow scheme created in step 6 (Steps to reproduce).
Select the "text" option - The following error is presented: "The Jira Server was contacted but has returned an error response. We are unsure of the results of this operation".
Reviewing the log files, we can observe a NullPointerException error:
NullPointerException when executing EditWorkflowScheme.jspa
1
2
3
4
5
6
7
8
9
10
11
12
2020-10-18 14:13:26,063-0300 http-nio-8080-exec-20 WARN isabel 913x845x1 1rtokm0 127.0.0.1 /rest/projectconfig/latest/workflow [c.a.jira.workflow.AbstractJiraWorkflow] Workflow 'MyScrum' contains step 'In progress' (ID:2) which is linked to non-existing status (ID:10100)
2020-10-18 14:13:26,064-0300 http-nio-8080-exec-20 ERROR isabel 913x845x1 1rtokm0 127.0.0.1 /rest/projectconfig/latest/workflow [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: null
java.lang.NullPointerException
at com.atlassian.jira.projectconfig.rest.project.WorkflowResource.getWorkflowSources(WorkflowResource.java:167)
at com.atlassian.jira.projectconfig.rest.project.WorkflowResource.createWorkflowResponse(WorkflowResource.java:123)
at com.atlassian.jira.projectconfig.rest.project.WorkflowResource.lambda$getWorkflow$1(WorkflowResource.java:112)
at io.atlassian.fugue.Either.leftOr(Either.java:356)
at com.atlassian.jira.projectconfig.rest.project.WorkflowResource.getWorkflow(WorkflowResource.java:111)
at com.atlassian.jira.projectconfig.rest.project.WorkflowResource.getWorkflowWithSources(WorkflowResource.java:89)
[...]Reference:
Error 4: Associating to another workflow from the invalid workflow threws NPE
Conditions to reproduce this issue:
At the Admin > Issues > Workflow scheme, edit the invalid workflow scheme created in step 6 (Steps to reproduce).
Select the "Add Workflow" button and the option "Add Existing"
Select another workflow to be used by this Workflow scheme. For instance, the previous workflow used prior to associate to the invalid workflow
Select the issue types that will use the workflow and press <Finish>.
The screen asking to associate status will be presented. Press the "Associate" button to start associating the issue types from the old status to the new ones.
Observe that the page remains unresponsive while running http://<jira>/secure/project/SelectProjectWorkflowSchemeStep2.jspa.
After some time, the Browser shows "Oops - an error has occurred" with HTTP Error 500.
Reviewing the log files, we can observe a NullPointerException error:
1
2
3
4
5
6
7
2020-09-04 20:17:09,477-0300 http-nio-8080-exec-19 ERROR [c.a.j.web.servlet.InternalServerErrorServlet] {errorId=30ca5694-1577-4611-97e3-dfe36832d12c, interpretedMsg=, cause=java.lang.NullPointerException, stacktrace=java.lang.NullPointerException
at com.atlassian.jira.web.action.admin.workflow.scheme.SelectProjectWorkflowSchemeStep2.getSelectListName(SelectProjectWorkflowSchemeStep2.java:183) [classes/:?]
at com.atlassian.jira.web.action.admin.workflow.scheme.SelectProjectWorkflowSchemeStep2.addMigrationMappings(SelectProjectWorkflowSchemeStep2.java:136) [classes/:?]
at com.atlassian.jira.web.action.admin.workflow.scheme.SelectProjectWorkflowSchemeStep2.lambda$doExecute$0(SelectProjectWorkflowSchemeStep2.java:105) [classes/:?]
at com.atlassian.jira.workflow.DefaultWorkflowSchemeManager.waitForUpdatesToFinishAndExecute(DefaultWorkflowSchemeManager.java:871) [classes/:?]
at com.atlassian.jira.web.action.admin.workflow.scheme.SelectProjectWorkflowSchemeStep2$DraftWorkflowSchemeHelper.waitForUpdatesToFinishAndExecute(SelectProjectWorkflowSchemeStep2.java:334) [classes/:?]
at com.atlassian.jira.web.action.admin.workflow.scheme.SelectProjectWorkflowSchemeStep2.doExecute(SelectProjectWorkflowSchemeStep2.java:101) [classes/:?]
Reference:
Error 5: Agile Reports affected
Conditions to reproduce this issue:
Select a Project Area with an active Sprint;
Change this Project Area workflow scheme to the invalid workflow scheme, with some invalid status;
As part of the process to associate a new workflow scheme, all the issues status will need to be mapped to the new status;
However, as the new workflow does not have all the status, it will not be possible to select the appropriate status. Users can proceed with the error, selecting another status;
After changing the scheme, although all the issues were mapped to existent status, they are not more visible at the board, active sprint, or reports.
Cause
The exported workflow contains the Status ID used by the step. This Status ID was created at the Source Environment, and the same ID may not exist, it may be already in use by another Status or the status may already exist, but with another ID. Some samples:
Source ID | Source Description | Target ID | Target Description | Action |
|---|---|---|---|---|
10100 | To approval | 10500 | For approval | It could reuse the status as they have similar meanings |
10101 | Under Development | - | - | It needs to be created |
10105 | To test | 10100 | To test | It already exists, but with a different ID |
It is not possible for the Import Process, to find which would be the correct action to do for the Status, depending on manual adjustments.
Solution
We need to identify for each workflow step if the status used is correct, duplicated, or missing.
1. Review information from the Source Workflow:
Edit the workflow XML imported using an external XML viewer of text editor
For each step, identify the status (id and name), where:
1 2 3<step id="3" name="The STEP name"> - Contains the name of the step <meta name="jira.status.id">10007</meta> - Contains the ID of the status <action id="41" name="The status name"> - Contains the transition action
Identify the Categories used for each status ("To Do", "In Progress", "Done") at the Admin > Issues > Statuses page:
Status | Status ID | Category |
|---|---|---|
Open | 1 | To Do |
In Progress | 10100 | In Progress |
Testing | 10200 | In Progress |
Closed | 6 | Done |
2. Review information from the Target workflow:
Check all available Status at the Admin > Issues > Statuses page;
Read the "ISSUESTATUS" table to get the ID of each status:
1
SELECT * FROM "ISSUESTATUS"
3. Identify the correct Status ID and required steps
This auxiliary table will help to understand the required actions to adjust the Status ID at the Target environment:
Source Status | Source Status ID | Source Category | Target Status | Target Status ID | Target Category | Required actions to fix |
|---|---|---|---|---|---|---|
Open | 1 | To Do | Open | 1 | To Do | ✔️ |
In Progress | 10100 | In Progress | In Progress | 3 | In Progress | Update Status ID to 3 from 10100 |
Testing | 10200 | In Progress | - | - | - | Create a new status |
Closed | 6 | Done | Closed | 6 | Done | ✔️ |
4. Create each missed status:
Reach Admin > Issues > Statuses;
Click the button "Add Status";
Insert the missed Status and select the category;
Identify the new Status ID created running the following query, replacing xxx with the inserted status:
1SELECT * FROM issuestatus where pname = 'xxx';
Source Status | Source Status ID | Source Category | Target Status | Target Status ID | Target Category | Required actions to fix |
|---|---|---|---|---|---|---|
Open | 1 | To Do | Open | 1 | To Do | ✔️ |
In Progress | 10100 | In Progress | In Progress | 3 | In Progress | Update Status ID to 3 from 10100 |
Testing | 10200 | In Progress | Testing | 10100 | In Progress | Update Status ID to 10100 from 10200 |
Closed | 6 | Done | Closed | 6 | Done | ✔️ |
5. Update Workflow with the correct Status ID
At the target environment, search for the imported workflow, where "MyScrum" is the workflow name
1
SELECT * FROM jiraworkflows where workflowname = 'MyScrum' 
Extract the descriptor column using CSV format and the Workflow ID returned by the previous query:
1
Copy (SELECT descriptor FROM jiraworkflows WHERE id = 10300) to '/tmp/desc.csv' DELIMITER ',' QUOTE '''' CSV;Using an XML Editor, change the Status to the correct Status ID:
Copy the full XML and update the workflow with the changed descriptor
1UPDATE jiraworkflows SET descriptor = '<paste here the full edited descriptor>' where workflowname = 'MyScrum';ℹ️ In some Oracle Databases, the above Update query will fail if the descriptor value is >4000 characters, which it usually is. To work around this, the descriptor value should be split into smaller strings and concatenated according to the clob format, like this:
1update jiraworkflows set descriptor = ( to_clob( 'part 1 of xml' ) || to_clob( 'part 2 of xml' )) where workflowname = 'MyScrum';
6. Restart Jira Servers to refresh caches
After the changes, restart your JIRA Instance. For JIRA Data Center, a rolling restart was found sufficient to clean up all caches used to store Workflow configuration.
7. Recreate all affected Boards
All Boards using the impacted Project Area or using a filter that does not have "Project" at the filter clause will remain impacted.
Recreating the board with the same filter addresses the problem.
8. Agile Reports
There will be Scope changes due to the invalid status:
Before changing the workflow:
After fixing the invalid workflow:
Additional information
Related articles
Unable to utilize imported or restored workflow in Jira server
Removing Workflow Step Fails with No status with that ID could be found, it may have been deleted
A useful groovy script to check all workflows for steps with an invalid status
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/**
* Groovy script to check all workflows for steps with an invalid status
* Courtesy of @Matt Doar
*/
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.workflow.JiraWorkflow;
import com.atlassian.jira.config.StatusManager
/**
* Check all workflows have a valid status for each step.
* Jira doesn't check this when importing workflow XML.
*/
result = new StringBuffer()
def wfm = ComponentAccessor.getWorkflowManager()
def statusManager = ComponentAccessor.getComponent(StatusManager.class)
for (workflow in wfm.getWorkflows())
{
for (step in workflow.getDescriptor().getSteps())
{
statusId = step.getMetaAttributes().get(JiraWorkflow.STEP_STATUS_KEY)
status = statusManager.getStatus(statusId)
if (status == null) {
result.append("ERROR " + workflow.name + "<br/>")
}
}
}
return result.toString()Note:
⚠️ This groovy script relates to customizations in JIRA Applications and it requires a third party plugin (Adaptavist ScriptRunner). Consequently, Atlassian Support cannot guarantee the provision of any support for the code as customizations are not covered under Atlassian Support Offerings. Please be aware that this material is provided for your information only and that you use it at your own risk.
Was this helpful?