When editing an issue during transition, (not available) may be appended to some custom field types.
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
During a transition, Changing a Parent value in the following custom field types to "none" and saving will result in having to save the transition a second time and will display a duplicated value with (not available) appended to it.
Select
Multi select,
Cascading Select,
Radio
Checkbox
See:
Steps to Reproduce:
Create a Cascading Select in the custom field configuration for a Project.
Mark it as Required (Administration --> Issues --> Field Configurations)
Create a transition that uses a screen that has the Cascading Select.
Create an issue and select a parent and child issue. Save it.
In the Issue window, click on the Transition to edit the values.
Under Parent select option, change to (none).
Save the edit.
Note that the save doesn't get written yet.
Observations:
Selecting (none) results in a message saying the field is required.
A duplicate option shows up with (not available) appended. (see attached screenshot)
You can save after this, even without making changes. The issue will commit the last "known good" selection.
Note that the previously used value is defaulted due to code changes in 8.8.0 to prevent data loss (likely the result of )
Environment
8.13.9
Cause
This behavior was introduced during a bug-fix attempting to prevent data loss. https://jira.atlassian.com/browse/JRASERVER-62455 has more details.
Background:
If an issue has a selected option saved in the database, that option will always be present in the edit form - even if the configuration of the field has been changed. The options not present in the configuration will have a "(not available)" suffix in their names. This prevents accidental data loss and allows users to edit parts of the issue without forcing them to change the historical values if custom field configuration changes.
Please follow this Engineering Ticket for any developments: https://jira.atlassian.com/browse/JRASERVER-72846
Solution
đź’ˇ Workaround to avoid end-user confusion:
1. Create a copy of <atlassian install directory>/atlassian-jira/WEB-INF/classes/com/atlassian/jira/web/action/JiraWebActionSupport.properties for backup purposes.
2. Change the line:
customfield.not.available.in.scheme={0} (not available)
to
customfield.not.available.in.scheme={0}
3. Restart Jira
This will not prevent a second entry from showing in the Transition, but it will remove the (not available) tag from it and hopefully avoid end-user confusion. You will still have to save the transition twice.
quote
Was this helpful?