Trying to import a project in Jira that was accidentally dropped and getting Custom Field errors

Sangeeta Verma February 13, 2018

A project was dropped accidentally a few days back.

1. Jira database was restored on a test VM.

2. An export was created from this restored database on test VM.

3. Trying to import that single project from xml export file in production and getting the following errors-

Error - The custom field "Reviewed' requires option'No' for the import but it does bot exist in the current Jira instance.

There are quite a few more errors like the one above for custom fields.

 

1 answer

0 votes
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 13, 2018

It sounds like you are using the project import option to try to restore the project settings.  That actually won't work 100% in regards to restoring all the project settings.  The project import is designed to import issues in a project.  It does not actually have the ability to import configuration settings like workflows, screens, or in this case, custom field configurations.

Not all hope is lost though.  If you check out the guide in Restoring a project from a backup, it explains that the destination Jira instance tends to require a lot of prep work before you can import this data.

I would recommend that you return to this Jira instance that had the complete backup restored it to.  From there you will need to see if this project was using a customized field configuration scheme.   Once you can identify what field configuration scheme was in use by this project, you can then look at the settings for that scheme in this Jira instance to see what custom fields exist there, and then see if any of these have specific contexts for this project.

I suspect that you are going to need to recreate any/all custom fields and/or their contexts in this project before you can successfully restore this data.  I would suggest reviewing Configuring a custom field for more information.

Sangeeta Verma February 14, 2018

Thanks Andrew for your reply. I'm very new to Jira administration and trying to resolve this issue.

I'm using project import option to import lost project. I created a project manually and all the selected options are matching in source and target instance in the summary field. Is there a way I can check custom fields set for a project only and not for the Jira instance?

For example when I check custom field "Review', all the configurations look the same both in source and target but I still get the following error.

The custom field "Reviewed' requires option'No' for the import but it does bot exist in the current Jira instance.

So is there a way to check this custom fiels on Project level?

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 15, 2018

The project settings won't be able to tell you specifically how the custom field is defined.  Projects can determine which fields exists on which screens in the field configuration schemes, however these do not tell us enough information about how that field is setup.

Let's focus on the field itself.   What kind of custom field is Reviewed?  Is this a select List (cascading, multiple choice, or single choice) or is this a Text field (multiline, readonly, single line)?   I suspect this is some kind of select field, but it's important to understand what kind.   Also if this is a select field single choice, then you should see a page like this:

reviewedfield1.png

To reach this page in your source instance, navigate to the Cog Icon -> Issues -> Custom fields.  Then find this 'Reviewed' custom field, and select configure. 

In my example above this custom field has two different contexts: One context for a BIZ project, and a different context for my SCRUM project.  In the scrum project, this field has the options 'Yes' and 'No'.  However for the BIZ project, the options for this field are 'In review' and 'Done'.  

It is important to make sure that this field in the destination instance will allow you to provide a value of 'No' for that field.   Another way to test this part is just to create a test manually in the destination Jira instance in that project and see if you can edit the issue to set the value to 'No'.   At least trying this should at least tell us more about the field type, and what options currently exist for that specific field as it applies to that project.   Please let me know the results.

Andy

Suggest an answer

Log in or Sign up to answer