We are performing the JIRA Consolidation running on same version of JIRA 7.2.2
Using the Project Configurator plugin, we exported the project configuration from 'A' JIRA instance and imported into the 'B" JIRA instance. Then, were able to export the XML backup from 'A' JIRA instance and imported each project into the 'B" JIRA instance. Almost all Projects were imported successfully.
However, we are encountering issues with Only two Projects.
Error Message:
1 -
The custom field 'Complexity' requires option 'L' for the import but it does not exist in the current JIRA instance.
The custom field 'Complexity' requires option 'M' for the import but it does not exist in the current JIRA instance.
The custom field 'Complexity' requires option 'None' for the import but it does not exist in the current JIRA instance.
The custom field 'Complexity' requires option 'S' for the import but it does not exist in the current JIRA instance.
2 - The custom field 'Department Code' requires option '5128' for the import but it does not exist in the current JIRA instance.
The custom field 'Department Code' requires option '5134' for the import but it does not exist in the current JIRA instance.
We verified the custom field configuration and options and everyting looks similar to the 'A' JIRA instance.
We even changed the Custom field context to Globally in both the 'A' (Source) and 'B' (Target) instances.
We are still facing the same issue,
Can you help us identify the root cause to fix this issue ?
Thanks,
Kiran.
Hi Kiran,
As you have created also an issue at Project Configurator issue tracker, I am answering there and include a link here to that issue.
You are welcome!
For convenience, I will copy here the analysis of this problem and a way to fix it. Please see more details at the issue tracker.
There is a bug in JIRA project data restore functionality that produces this error if, at the source database, a custom field configuration scheme is associated to a custom field configuration and both of them do not have the same ID. You could check if this is happening in your case running this query on the source database:
select * from fieldconfigschemeissuetype where fieldconfigscheme!=fieldconfiguration
If this query returns any row, then those are candidates to suffer that problem. Taking the value from the fieldconfiguration column in those rows (let us say it is XXXX) you can run these queries:
select * from fieldconfiguration where id=XXXX select * from customfieldoption where customfieldconfig=XXXX
The first will show you the impacted custom field configuration (whose name usually contains a reference to the custom field name). The second query willl show impacted options, so that you can verify if they are the same options that appear in the error messages in this case.
This can be fixed changing the source data, so that those 4 custom field configurations have the same id as their parent custom field configuration scheme. You could do it on the source database directly, or editing the exported .zip file (this is certainly safer, if anything goes wrong the source database would still be intact).
I've seen this a couple of times. I'm not sure if it's a bug. Could you physically check the complexity and department code fields in the target JIRA - not check that "everything looks similar", but actually check for the missing options?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Nic Brough [Adaptavist],
We verified that both the custom fields have same options in both source and target.We also tried changing the target custom field options to match with that of source field, but no luck. We are unable to figure out what is causing the issue. Could you please mention what could be other causes?
Thanks so much!!
-Swathi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, that's not what I asked.
Please check the options in the target JIRA are there in the option lists for the fields. The source JIRA is irrelevant.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.