Status: Closed (View Workflow)
Affects Version/s: 6.4.14, 7.2.1, 7.1.9, 7.2.8, 7.7.2, 8.5.1
Component/s: Issue - Fields
Introduced in Version:6.04
Support reference count:39
Symptom Severity:Severity 1 - Critical
Bug Fix Policy:
Current Status:Atlassian Update – 13 Mar 2020 Hi everyone, I'm happy to announce that the data loss issue has been fixed starting from Jira 8.8.1 and 8.9.0. There are five custom field types affected by this bug - select, multi select, cascading select, radio, and checkbox - and each of them has been patched. 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. Thank you, Daniel Rauf Jira Server Developer
When a custom field configuration is edited and then an issue using that configuration is edited, the custom field values revert to null or the default option.
Users are not likely to notice unless they are attempting to change that field. If they do happen to notice they cannot see the original value in order to restore it to the correct value.
- Create a Custom Field called "Test" using the "Select List (single choice)" type.
- In the default/Global field configuration, configure three options: A, B, C.
- Create an issue in Project FOO and set the field value to "B".
- Create a new custom field context.
- Configure the same three options for the field in this configuration: A, B, C.
- Configure Project FOO to use this field configuration for the type of issue you created in Step 3.
- Click "Edit" for the issue you created previously.
- After the field configuration is changed, existing values for the field should be preserved unless they cannot be mapped to options in the new configuration.
- Alternatively, JIRA should highlight the modified field values in some way so the user knows they must make a change in the Edit screen.
- If the user does not modify anything on the "Edit" screen and clicks update, the field value will be changed to either 'None' or the first available field option.
- If the field is optional, the field will be set to 'None' in the Edit screen.
- If the field is required, the field will be set to the first available option, not the default option, in the Edit screen.
Administrators: After changing the field configuration for a project, for each custom field value you wish to preserve...
- Search for issues that have the custom field set to that value.
- Bulk edit the issues to set them to the correct value in the new field configuration (even if that value matches the default field config)
Detailed description and steps for the workaround are at Change Context for an Existing Custom Field Without Losing Old Data.