-
Type:
Suggestion
-
Resolution: Unresolved
-
Component/s: Global Administration - Fields Management
-
None
-
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).
- Populate data for this custom field across several issues within Project A.
- 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).
- Observe that the Jira UI prevents saving the context configuration because it cannot be left with zero projects.
- In order to free the project, delete the context entirely.
- 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).
- 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).
- Safely associate the production project with its new desired custom field context.
- Delete the old context containing only the dummy project.