Are select list options in different configurations different values?

[Ken Wood]

For custom field X there is configuration A with the options

   L
  M
  P
  V

For the same custom field there is a different configuration B with the options
  L
  M
  N
  O
  P
  Q
  V

If an issue is being cloned from a project that is using configuration A and then being moved to a project using configuration B, and "X" is a required field in the destination project, I'm getting a message that I have to provide a value for "X"

In the original issue (and therefore the clone), "X" has the value 'M'. And in the destination project the option 'M' is available, but the move apparently isn't using that, instead it's asking for a value.

I believe the reason is that, under the covers, the 'values' of the options in each configuration are different, even though some have the same name for the option. So as far as the move operation is concerned, the issue doesn't have a value for X in the destination project.

Am I on the right track, or is something else going on here I need to understand.

[Nic Brough -Adaptavist- · Accepted solution]

Your belief is correct.

When we look at a custom field, it has a load of "options".  Each one of these has several attributes, which include (but are not limited to) - a unique id, a display name and a flag to say whether it is currently active.

To (over)simplify your case, and look directly at the database, part of what you have might look like:

• Context 1:  ID: 1 Name L
• Context 1:  ID: 2 Name M
• Context 1:  ID: 3 Name V
• Context 2:  ID: 4 Name L
• Context 2:  ID: 5 Name M
• Context 2:  ID: 6 Name V

The move process has no idea about the names.  (It can't because you can translate them as well as use whatever you like for them).  If you try to move say ID:2 into a project using context, Jira has to ask "from 4, 5 and 6 which are valid here, which one should I move to?"

TLDR:  You're right, options are separate.