On this page:
Custom field context deletion
We aim to manage custom field contexts and their options as sophisticated as possible during the:
cloud-to-cloud Jira configuration deployments, and
server-to-cloud Jira migrations.
Yet, sometimes, you might face the following error in the Analyze changes phase of the migration/deployment wizard:
‘Custom field context with id ‘context_id’ and name ‘context_name’ will be deleted with its options from the destination. Deletion will cause a loss of the option values in issues. See how to resolve this case in our documentation.’
In these cases, the migration will stop with the error above. Then, you would need to configure the contexts in your Jira systems by yourself to prevent the deletion case and error from ever occurring.
To give you the tools to avoid such situations, first, we need to go through how we evaluate the source and destination contexts to find out if they match.
How do we evaluate and match source and destination contexts?
You should first know that for each custom field, CMJ Cloud exports the contexts only of the projects in the deployment/migration scope. These are either the global contexts or contexts for the projects in the migration/deployment scope.
The contexts in the deployment/migration scope do not contain references to projects outside the scope. Even if such are present on the source Jira system, CMJ Cloud won't include them in the deployment/migration.
Suppose a context needs to be deleted from the destination Jira Cloud and has references to multiple projects. In that case, CMJ Cloud will remove only the references to the projects in the migration/deployment scope from the context. The global context is never deleted from the target system, as this may affect many projects.
While comparing the source and target contexts, we identify them by the projects they are assigned to. Suppose we have a source context assigned to projects A, B, and C. Whereas, on the destination we have a context assigned to projects C, D, and E.
You start a migration/deployment, add projects to it, and that source context ends up inside the scope. CMJ Cloud compares the source and destination contexts in the analysis phase. It will find out that project C is assigned to both source and destination contexts. The app will remove project C from the destination context and will add the source context as a new context for projects A, B, and C to the destination.
The problem comes when you have a destination context and all its projects are present in a source context. Then, CMJ Cloud will attempt to execute its logic from above to remove the source projects from the destination context. As a result, this will leave the destination context without any projects, and it should automatically become a global context. CMJ Cloud can’t let that happen on the destination, as a project can have only a single global context. That’s why it stops the deployment on the Analyze changes phase and shows you the error about the potential consequences of deletion.
How to resolve the context deletion error?
If the context deletion works for you, we recommend removing the context from the custom fields it’s assigned to on the destination Jira Cloud by yourself.
Remember that deleting a context is an issue only for custom fields with options. The values of the options will be gone together with the context.
If deleting the context isn’t an option for you, we recommend making adjustments to the source Jira system. You need to make sure the projects you’re deploying/migrating wouldn’t cause such an error. Refer to the logic we explained in the previous section when making the changes to the source Jira.