Issue Type migration forcing assignee to reset to default?

[Greg Bryant]

We are doing a major (for us) migration, moving a proliferation of workflows into a unified process, changing our issue types, and re-organizing our projects. So far, it's been about as smooth as anyone would expect (given limitations on bulk copy, limitations on changing closed issues, all the usual), but we just ran into a new one. For this one existing project, which has been migrated to the new workflow already, we are trying to migrate to the new issue type scheme. It is currently using a scheme called "Agile Scrum Issue Type Scheme", which I would kind of guess was created by Jira Agile. When I try to migrate to the new scheme, I have seen in previous projects a box where I would be asked to set the assignee (a required field), with a check box to retain the previous value, for types that had to be changed. Check the box, and everything is happy.

In this project, however, I get a big warning box that says "The value of this field must be changed to be valid in the target project, but you are not able to update this field in the target project. It will be set to the field's default value for the affected issues." There is no "retain" option. Now, the project is not changing, so the bit about "target project" is a bit misleading; I have admin privilege here (and everywhere else that's already been done), so no problems with permissions, and only one of the two fields that must be changed is throwing this message, the other is perfectly happy. Again, this about the 10th project that we've migrated, and all the others were perfectly happy to let me change the issue type and retain the value for assignee.

I am certainly not about to throw away the assignee field for these issues (this is a smallish project, but still too large to make it feasible to hand recreate those), but there's also no way I'm about to hit that Next button without knowing what's going on. I found nothing online about this message, or what it really means. Does anyone know what's going on with this particular project?

[Tarun Sapra · Accepted solution]

Some of your old issues might have assignees that no longer have "assignable user" permission in your project thus you can't retain them.

[Greg Bryant]

That makes sense, but it also falls under one of those "I'm an admin, why can't I do this" kinds of questions that makes JIRA so incredibly opinionated. I can change the issue type manually for every single one, but I can't do a bulk move without losing data?

[Tarun Sapra]

You might loose some data if you do bulk move, thus my suggestion is do it first on test machine, and then see which assignee have gone missing and then update those in production with project lead and then do issueType migration. But to be honest the whole User Experiencce of IssueType migration is pretty crappy I have raised a ticket about it with Atlasssian as I have myself lost data on production and had to restore it from the latest backup. https://jira.atlassian.com/browse/JRA-36801

[Tarun Sapra]

Also, You can loose your custom field data permanently if you haven't mapped the custom field to the new issueType, please see the above JIRA ticket link that I have posted

[Greg Bryant]

The only way I've found to make this change is the one at a time - display the issue (details view works), and then click the edit button next to the issue type and change it to something else in the current set of issue types. Then the issue types migrate just fine.