On this page:
| Table of Contents |
|---|
Custom field context deletion
We aim to manage custom field contexts and their options as sophisticated with maximum precision 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 'Custom field context with id ‘context'context_id’ id' and name ‘context'context_name’ 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 explain 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 systeminstance, CMJ Cloud won't include them in the deployment/migration.Suppose a context
| Info |
|---|
What happens if a context must be deleted from the destination?More specific is the situation when a context with references to multiple projects needs to be deleted from the destination Jira Cloud |
...
during the deployment. In that case, CMJ Cloud will remove only the references to the projects in the migration/deployment scope |
...
. 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. Global contexts are never deleted from the destination Jira sites, as this may affect many projects. |
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 it's assigned to on the destination Jira Cloud by yourselfmanually.
Remember that deleting a context is an issue only for custom fields with options. The It's a problem as the values of the options in issues will be gone together with the context.
If deleting the context isn’t isn't an option for you, we recommend making adjustments to the source Jira systeminstance. You need to make sure the projects you’re you're deploying/migrating wouldn’t wouldn't cause such an error. Refer to the logic we explained in the previous section when making the changes to the source Jirainstance.