Switching Workflow Scheme: Why do I need to update the current status for all issue types?

[Caela Northey]

I'm trying to switch a project's workflow scheme, but the second step is asking me to map the current statuses to new ones for every issue type we use in our instance, not just the types specified in the Issue Type Scheme for the project. I'd like to know why this is, and if there is a way to avoid it as we have a large number of issues types.

We are using JIRA server 6.3, and here is all the Atlassian documentation says about this step (Step 2 of 3: The current status of each issue needs to be changed so that it is compatible with the new workflows):

Each issue has to be in a valid status. The valid statuses for an issue are defined by its workflow. This means that when changing a workflow, you may need to tell JIRA the status for specific issues after the change.

Any feedback is appreciated.

[Nic Brough -Adaptavist- · Accepted solution]

It is doing what it says - it needs to know what to migrate the current status to.

There should be a count of the issues affected next to each one though - if that is zero, you can accept the default and ignore it, as it won't have any effect.

[Caela Northey]

Ok, most of them are zeros since the project only uses a small subset of issues types. Makes sense that it wouldn't be any effect tho, thanks for the (speedy) reply.

Any idea why it requires that for issue types outside of the project's scope however? It's still going to be a pain to sort thru the list looking for the issues types used, and I have definitely switched schema before without that big of a list needing mapping. Just curious.

[Nic Brough -Adaptavist-]

Slightly lazy design or coding I think - the screen doesn't bother to read the current issue type scheme, because it's easier not to.

[Daniel Wester]

I suspect the main reason is that there is a possibility of phantom workflow statuses (or at least there were in older versions of JIRA) when migrating large projects (it goes issue by issue). I've encountered an issue being stuck in a Status that doesn't exist in the workflow (eek!) because somebody migrated the issue right after JIRA had processed the issue (but before the new workflow was switched to). Rerunning the migration fixed that...