Programatically change workflow name and publish

[Mihaela Ienea]

Hello,

We are developing a plugin that can change via the user interface the workflow name (plugin available only for admins).

The problem after renaming the workflow, is that the issues are in an inconsistent state and those can not be transitioned anymore.
I'm using method 

workflowManager.updateWorkflowNameAndDescription 

 After this, I am replacing the draft workflow

workflowManager.overwriteActiveWorkflow(currentUser,newWorkflowName);

  and in the end update the workflow scheme

WorkflowSchemeManager workflowSchemeManager = ComponentAccessor.getWorkflowSchemeManager();
Iterable<AssignableWorkflowScheme> schemes = workflowSchemeManager.getAssignableSchemes();
for (AssignableWorkflowScheme scheme : schemes) {
    workflowSchemeManager.updateSchemesForRenamedWorkflow(getWorkflowName(), newWorkflowName);
}

Even so, the issues can not be transitioned anymore;

I can not find another method to publish the changes, neither on the workflow or in the workflow scheme;

If there is any other known method that can do this, please provide some hints

Thank you

Mihaela

[Radek Dostál]

Whenever you modify anything with workflow scheme mapping (or remove workflow statuses but that's a different topic), you have to "migrate" existing issues. Think of it like what happens if you go into the project, associate a new a workflow, and Jira will go through a bulk edit process to propagate the workflow for the issues.

There is a method from WorkflowManager that can do it: https://docs.atlassian.com/software/jira/docs/api/9.12.12/com/atlassian/jira/workflow/WorkflowManager.html#migrateIssueToWorkflow-com.atlassian.jira.issue.MutableIssue-com.atlassian.jira.workflow.JiraWorkflow-com.atlassian.jira.issue.status.Status-

Essentially, you need to keep track of which issue types you are affecting by changes in scheme mapping, and then you want to iterate over the issues and use this method to "fix" the issues so that they are mapped to the correct workflow.

So param1=issue; param2=newWorkflow; param3=issue.getStatus()

So in practice something like this

workflowManager.migrateIssueToWorkflow(mutableIssue, newWorkflow, mutableIssue.getStatus());

I may be wrong because it's been years since I last touched this and I am making an assumption. However, all issues are mapped to a "workflowId" property. When you overwrite an active workflow (from a draft), it changes the workflow's id. Meaning, all issues that were using that workflow get frozen, as you're seeing right now.

So that is why you need to migrate all such issues so that they can refer to the (new) workflow id.

[Philipp Sendek]

Hi Mihaela,

welcome to the community.

I haven't been in this situation, so here's my assumption:
It sounds to me that the status of the issues became disconnected with the Workflow steps, as those have changed with the change of workflows. Which is what one part of the Integrity Checker is created for.

If this is correct, you could check whether there's a way to trigger this integrity checker - or the action it performs - through the API. There's also the way to run the actual DB queries (KB article), but I don't think it's encouraged for Apps to interact with the DB directly.

Greetings
Philipp