Issue Summary

When creating or updating issues via the Jira REST API, if a select list custom field contains multiple options with the same display name (some active, some inactive), and the client sets the field using the "value" (label) instead of the option "id", Jira may select an inactive option.

This results in issues being tagged with inactive options, even though an active option with the same name exists.

Steps to Reproduce

1. In Jira administration, create a select list custom field, e.g.: Name: Team
2. Ensure the field has at least 3 options with the same label:
   • Highguard – ID: 1001 – Inactive
   • Highguard – ID: 1002 – Inactive
   • Highguard – ID: 1003 – Active
     • IDs are examples; any real IDs will reproduce as long as there are duplicates with the same value.)
3. Using the Jira REST API, create or update an issue and set the field by value:

   {
     "fields": {
       "customfield_XXXXX": {
         "value": "Highguard"
       }
     }
   }
   

4. Inspect the resulting issue in the UI or via REST (e.g. GET /rest/api/2/issue/ {issueKey}) and verify which option ID is stored for customfield_XXXXX.

Expected Results

When multiple options share the same label and only one is active, Jira should either:

• Prefer the active option when resolving "value": "Highguard", or
• Reject the request as ambiguous (e.g. 400 with a clear error), or
• Provide a configuration to ignore inactive options when resolving values.

In all cases, Jira should not silently select an inactive option when an active one with the same label exists.

Actual Results

Jira selects the first matching option internally, which in practice is often the oldest / lowest ID, even when that option is inactive.

As a result, newly created or updated issues end up with:

Team = Highguard (ID: 1001, Inactive) instead of
Team = Highguard (ID: 1003, Active).

This occurs consistently whenever duplicate option names exist, and the field is set via REST using "value". Note that if using the UI, Inactive options won't be available to users, which can cause additional friction for the user base.

As a result issues are being tagged with inactive options:

• Breaking reporting and dashboards that rely on active option values.
• Breaking downstream workflows and integrations that only expect active team values.

Workarounds

1. Use option IDs instead of values in REST calls
   • Retrieve the allowed options (including id, value, and disabled/active flag) via REST, then send:

     {
       "fields": {
         "customfield_XXXXX": {
           "id": "1003"
         }
       }
     }
     

2. De-duplicate / rename inactive options
   • Rename inactive duplicates (e.g. Highguard (inactive 2025-01)) or migrate data and delete them so only the active option uses the plain label.