Can´t retain values by changing Issue Type in a Scheme + Project

[Michael Ries]

So I have some cleaning up to do in my Jira instance. Now I found some old issue type duplicates because of language settings.

Basically what i wanna do is, change one issue type to another, and finally when no more projects are related to said issue type I can finally delete it.

Now from my understanding, an issue type is a "name" and a "symbol" and that´s about it. But when i try to change the issue type i get some weird problems. So now i had to find out that for some reason issue types are bound to fields, what doesn´t really make any sense from a front end pov.

Example:

I have an issue type scheme, which is linked to let´s say 3 projects. I wanna change 1 issue type in said scheme from 1 to another.

Now i get the message, that i have to update field values. (again i understand that it is connected to the field scheme but i don´t understand why) So i try to "retain" the values, because let´s keep the values as is, right? wrong!

For some magical reason, Jira is not able to just keep the values, but to change all values to 1 certain new value, even when i try to retain it.

For the case "assignee" i found the problem. Because sometimes e.g. in old projects there are assignees in tickets which don´t have the same role/permission anymore. So when Jira is trying to create the new issues (instead of changing just Name and Symbol of said type) they aren´t "available" so to say.

But what reason, prevents Jira to just retain the same field values? I mean Value = x right? so plz keep x in new field aswell and keep y = y.

How is this so hard, or am i missing anything here?

greetings

[Nic Brough -Adaptavist- · Accepted solution]

So, there's somthing here which you have got right, but also wrong, at the same time. 

It is not a surprise that you have missed it, it is not howled out on every doc page or support article, and it comes up a lot, which suggests that it's really not coming out properly in the docs or training.

You say: an issue type is a "name" and a "symbol" and that´s about it

In data terms, you are spot on.  The database holds a unique id, name, icon, and a couple of other trivial cosmetics.  In information terms though, "all your config are belong to us". You have misunderstood what the issue type does - it controls all the configuration for any issue of that type.

Every piece of configuration for issues hangs off the issue type.  It's not quite that simple, it's actually "issue type in this project".  (For example, you can make bugs in project A work differently to bugs in project B, but that's not the point here).

TLDR: Each issue type in a project is something you can configure separately.

The reason you are struggling with field data is that the issue types are configured to handle them differently.  Horribly simple answer, I know, but you seem to be asking to keep field values that simply do not exist on the target issue type.  You will need to enable those fields for the target issues if you wish to keep the values

[Michael Ries]

Edit: sorry i alrdy have to correct myself on this one; it is even more problematic for me to understand. Because i don´t even want to change the field config. I am only migrating issue types(scheme). So Jira asks: "Do you want to retain these values?" I tell Jira: "Yes please, take these issue types instead of the others" and Jira answers: "okay understood" and then it doesn´t or tells me i have to fill out a certain field.

So how is it so hard for jira to just take the issue type, keep everything the same. I am not even asking to change smth. I have the same field configuration in the background(project details) same fields should be possible. I also want to keep all values. Everything status quo; as it is! But for some reason jira is unable to do this? why? i just don´t get it.

So yeah edit but consens stays the same. I still need an answer to my problem. Like what is the actual problem I am missing here?

edit2: "You will need to enable those fields for the target issues if you wish to keep the values" - yes, but how? I alrdy have the same field configuration. I Tell Jira "retain the values" and provide jira with the same field configuration or better said I don´t touch it at all. So everything needed should alrdy be there, otherwise the migration just doesn´t work. Is that it? Does the migration just not function properly? then it shouldn´t even be an option imho.

If i tell you "keep value "5" in field "5"". The field is here before and after. "Just take the value put it in the same field as before just put the field on issue type x instead of y". This should be a simple task right?

So basically what you are implying is what i alrdy more or less figured out, but didn´t want to take for granted?

Meaning: Field Configuration is mapped to Issue types on a per project basis? This what you are saying? So as long as my Field Config and Issue Type Scheme is the same i can just change the schemes?

What i am missing here in your answer is a solution to my problem tbh: "I know, but you seem to be asking to keep field values that simply do not exist on the target issue type."

I´´m not really. I was just wondering why JIRA is trying to suggest i can retain field values when i in reality can´t. Why is jira not telling me what I have to change; e.g. if an assignee isnt there anymore u can put him/her back in the Project roles, then migrate and remove him/her again.

Or if persmission are misssing bcs we change the permission scheme (archieved project) i can chenge the permission scheme back and forth while migrating so that´s simple answer.

What I am asking is what i have to do to be able to use the retain function or/and what I have to do to be really able to migrate it flawlessly.

Because i tried to make the whole project settings exactly the same and still field values are getting messed up.

greetings

[Nic Brough -Adaptavist-]

Almost.  You've got the field configuration stuff spot on, but it's a lot more than that. 

Field configurations have little effect on a migration.  They generally define how a field is used at the time of change and display.  So if you were to move an issue to a different scheme (either by changing the scheme itself, swapping to a new scheme or moving the issue to a type that uses a different scheme), that will actually work.  If you've made an empty field mandatory, then the next time someone edits or updates that issue, Jira will force them to enter something.  If you've shown or hidden a field differently, that will apply (and newly hidden fields may be a problem if you're validating on them), and the field rendering may change.

But, as I said before, most of the configuration is hung off the issue type.  It's not just field configurations, it's the workflow, the screens and the fields themselves.

Screens are not a problem here, unless you make them incompatible with something else (I alluded to hidden mandatory fields earlier - same problem with changing screens).  It'll let you migrate without change, and people will get the "mandatory field, but not on screen to fill" problem.

Workflows and selection fields will block you and require migration.  Both of these have lists of valid values for the current context which mean it becomes complete nonsense to "retain" values - they require migration.

Imagine you have a field called "colour" - for issue type 1, (called visible primary colours), valid values are Red, Green and Blue.  For issue type 2 (called printable colours), the valid values are Cyan, Magenta, Yellow and Key.  It's nonsense to have an issue with a visible primary colour of Magenta and nonsense to have an issue with printable colour Red.

Next imagine a pair of workflows - Open, Doing, Closed, and To-do, In-progress, Done.  You can't possibly have an issue using one of those workflows while in a status from another because the workflow simply doesn't have it.

For both workflows and listed fields, you must migrate to valid values, or you would leave your issues in a state where they can't be used, either because their data is nonsense to the users or to Jira (and most likely, both)

The "retain" option in Jira simply attempts to map values when it can.

[Michael Ries]

noted and understood, but doesn´t solve or answer my problem.

The problem is, that i don´t try to change anything. You are talking about new fields and different workflows. That makes total sense to me. Ofc i need to map values to new fields.

But all I´m triyng to do is, tell JIRA to use a different Issue Type, but leave everything else as it is.

So imagine I have an issue type a called Task and i want to migrate to an issue type called incident.

I create said type. Call it incident. Pick a symbol. Choose a scheme. Remove task and put in incident.

Then Jira asks me which type i want to change. I pick Task -> incident.

So far so good.

What i would expect jira to do now is just "retain" all these values and change the type. How can this be so hard? I don´t want to change anything but the issue type and tell Jira "this was Task and now it is Inicident plz leave everything as it was before".

Where a field called "colour" has been; put the same field and the same value etc.

Dont change anything plz, but the type and icon.

it doesn´t work and i don´t understand why.

greetings

[Nic Brough -Adaptavist-]

I think you are missing the point.

The issue type determines how an issue works.

The issue type tells the issue what values are valid for fields, it tells the issue what fields are available and on what screens, it tells the issue if it's an issue-level, sub-task, or epic-level (and more layers provided by apps and external systems), it tells the issue what workflow to use.

It's structural and foundational. 

You can't say "this was a task and is now an incident", it's nonsense if the task is the wrong shape to be an incident.  You're trying to hammer a square peg into a round hole - you must change the shape of the peg to get it to ffit.

[Michael Ries]

I think you are missing the point. - i guess so

it tells the issue if it's an issue-level, sub-task, or epic-level - yes and no; there is only 1 issue type that works as epic and it is predefined. I can choose between Task(Level) and SubTask when creating an issue type.

it tells the issue what fields are available and on what screens - no, because I am telling the project what fields shall be used

it tells the issue what workflow to use -  no, because same goes for the workflow, that is on project basis

So if that is not the case, then I might see where you are coming from and the docu or basic teaching how jira does work is just not correct.

What I do understand is, that if I once told jira (project) to handle a certain project to create issues with certain settings, they got created and now i want to change those settings, that i have to migrate where migration is needed.

U said The issue type determines how an issue works. But that is exactly my problem. It doesn´t. On issue type creation I have next to no possibilities. I can do what i described earlier and i place the issue type in some scheme.

So the answer that is still unanswered is, where can i change that? or better how? And plz don´t tell me in the migration assistant because that is my problem in the first place and it is not working.

You're trying to hammer a square peg into a round hole - you must change the shape of the peg to get it to fit - not really, it is more like I´m having a square peg and dough, because i didn´t tell it anything and when I am using migration after putting it in the scheme. I am expecting Jira to put the dough in the mould and form it to a square peg aswell, but it doesn´t despite all parameters being the same and the newly created issue type is nothing but dough (I only told it, that it is Task-Level dough)

greetings

[Nic Brough -Adaptavist-]

So, some thoughts:

"it tells the issue if it's an issue-level, sub-task, or epic-level - yes and no; there is only 1 issue type that works as epic and it is predefined. I can choose between Task(Level) and SubTask when creating an issue type."

So yes, and it is very important to understand that those three groups work differently and hence are not the same.  Converting between the three absolutely is a square peg and a round hole.  It clearly is not dough.

"it tells the issue what fields are available and on what screens - no, because I am telling the project what fields shall be used"

No, you're not.  You're keeping it simple by only having one setup per project, but in the background they are not.

On top of that, fields are not controlled just by field configuration - there are screens and contexts too.  Even if you have a single set of screens and field configurations for a project, you can still make fields work differently by issue type, totally independently of the project.

"it tells the issue what workflow to use -  no, because same goes for the workflow, that is on project basis"

Same as the fields - it's still done by issue type, even when it is one per project

So, going back to the original question - no you can not "just change the issue type".  You can, in theory, if the configuration for the source and target type is identical, but you cannot expect it to be, and Jira will always need to check.

When the configuration is not compatible, you must change the shape of the issue to match the target configuration.  So, going back to the question again, no, you can not "retain" a value for a field when that value would be invalid for the field in the new issue type.

>So the answer that is still unanswered is, where can i change that? 

I am a little lost on what you are asking with that - what are you now trying to change, now that you've got a better grasp of why issue types are not a simple field?

[Michael Ries]

I also got the feeling that we got a little lost in the topic. Everything you pointed out i did alrdy or do now understand better than before. It helps my understanding about a few things in Jira and what can be missleading, though it doesn´t solve my problem.

"So, going back to the original question - no you can not "just change the issue type".  You can, in theory, if the configuration for the source and target type is identical, but you cannot expect it to be, and Jira will always need to check."

That is exactly my problem or at least i think it is. Everything is identical. I am not trying to substitute an (task-level)issue type with a (subtask-level) type.

My configuration are mirrored but Jira can still not retain values. "the configuration for source and target type is identical" - exactly it is identical, atleast in project settings and i wouldnot know where else to look, but still it doesn´t work. 

So here is my question: why?

[Nic Brough -Adaptavist-]

Because the target type is configured differently to the source and hence the old data is not valid for it.

You need to look at the configuration of the fields as well as the projects.  If the possible values for the fields were the same, you would not be asked how to change the data to match the new configuration.

[Stephen Lee]

Late to the party here, but I've been having the same issue. I'm using a nextgen project and have two different issue types (which are not at the subtask or epic level). I have 3 fields in particular that are configured for both of the issue types which take one or more People as values.

When moving an issue from Type A to Type B, the screen will show all 3 of those fields and ask for a new value, or to click the "retain" checkbox

When clicking the "retain" checkbox, it does not retain the values - they get cleared out (or I guess, they don't get set at all) as the issue transitions to Type B

I checked my `/rest/api/2/field` to see if they were perhaps duplicate field names with the same name, but I only see one instance of each of those fields in that list, so I think that means it is indeed the same field.

@Nic Brough -Adaptavist- you were mentioning other things like the possible values configured for the fields, and afaict they're set the same—it's just set to allow one or more People in both Issue Types.

Is there something else I can check, or is it possible there's a bug where `retain` doesn't actually work? 

Thanks!