nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Accepted answers

Nic Brough -Adaptavist-

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

All comments

Nic Brough -Adaptavist-

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

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

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

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software