Allow moving a project out of a project-scoped custom field context without forcing context deletion and data loss

XMLWordPrintable

    • 3

      When a custom field has a project-scoped context containing only a single project, Jira Cloud does not allow that project to be removed if it leaves the context completely empty. To migrate this project to a different context (e.g., a global context or another shared context), administrators are forced to delete the single-project context entirely to "free" the project.
      However, deleting a custom field context immediately purges all associated historical field values/data for that context. This creates a critical where moving a project out of its isolated context inherently results in permanent, irreversible data loss for that custom field.
      Note: This problem does not occur if the context houses multiple projects, as removing one project still leaves the context populated.
      Steps to Reproduce # Create a custom field with a custom context restricted to a single project (e.g., Project A).

      1. Populate data for this custom field across several issues within Project A.
      2. Go to Custom Fields > Contexts and try to modify the context configuration to remove Project A (with the intent to move it to a different context).
      3. Observe that the Jira UI prevents saving the context configuration because it cannot be left with zero projects.
      4. In order to free the project, delete the context entirely.
      5. Check the issues in Project A; all historical data for that custom field has been completely wiped out.

      Suggested/Expected Behavior * Allow an existing context to save with zero projects attached to it (treating it as an inactive or parked context).

      • OR: Provide a built-in migration/reassignment wizard when editing contexts, ensuring that moving a project directly from Context X to Context Y safely transfers or retains the underlying custom field values.
      • Context deletion should be a strictly explicit, separate choice, rather than a forced workaround to modify project mappings.

      Known Workaround
      Administrators can bypass this restriction and protect their production data by introducing a temporary dummy project: # Edit the problematic single-project context and temporarily add a dummy/test project to it (so it now contains two projects).

      1. Edit the context a second time to remove the production project, leaving only the dummy project inside. Save changes (Jira allows this because the context is not empty).
      2. Safely associate the production project with its new desired custom field context.
      3. Delete the old context containing only the dummy project.

       

              Assignee:
              Unassigned
              Reporter:
              vrayapudi
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: