Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-62455

Changing a custom field configuration changes the values of custom fields when issues are edited

XMLWordPrintable

    • 6.04
    • 39
    • Severity 1 - Critical
    • 516
    • Hide
      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

      Show
      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

      NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

      Issue Summary

      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.

      Steps to Reproduce

      1. Create a Custom Field called "Test" using the "Select List (single choice)" type.
      2. In the default/Global field configuration, configure three options: A, B, C.
      3. Create an issue in Project FOO and set the field value to "B".
      4. Create a new custom field context.
      5. Configure the same three options for the field in this configuration: A, B, C.
      6. Configure Project FOO to use this field configuration for the type of issue you created in Step 3.
      7. Click "Edit" for the issue you created previously.

      Expected Results

      • 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.

      Actual Results

      • 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.

      Workaround

      Administrators: After changing the field configuration for a project, for each custom field value you wish to preserve...

      1. Search for issues that have the custom field set to that value.
      2. 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.

              drauf Daniel Rauf
              vshanmugam Vicknesh Shanmugam (Inactive)
              Votes:
              90 Vote for this issue
              Watchers:
              94 Start watching this issue

                Created:
                Updated:
                Resolved: