nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Project import - 'Epic Color' and 'Epic Colour' issue

tim wilkinson

Hi,

I'm trying to import a project from another servers and getting an error:

"The custom field 'Epic Color' of type 'Colour of Epic' is required for the import but does not exist in the current JIRA instance. "

I've been reading a few posts about this and I know why I'm getting this error (it's due to UK English language being set as default on destination server and US English language being set as default on source server).

The solutions I've found involve either manually renaming the 'Epic Colour' custom field on the destination server to 'Epic Color' (or possibly changing the field name on the source server I suspect), or updating the database table.

I'm wondering if simply changing the default language on the source server to same language on destination server might also work. If I did this would it change the spelling and remove the conflict? I haven't seen this as solution to this problem but it would probably be the best solution if it works.

Cheers,

Tim

Accepted answers

Daniel Wong_zylx8x

Hi @tim wilkinson

Unfortunately changing the default language on your server won't change the field name of 'Epic Color'. This is a common problem when migrating projects between Jira instances.

The quickest way (which you've mentioned above) is to unlock the field on your source instance > Rename it to match the destination instance > Lock it back > Run the Project Import.

The KB article you're after would be here - https://confluence.atlassian.com/jirakb/project-import-fails-with-custom-field-xxx-of-type-xxx-is-required-for-the-import-but-does-not-exist-425462621.html

There is an alternative way which is to hack the XML export but that can go wrong very quickly so I wouldn't recommend doing that.

All comments

Daniel Wong_zylx8x

Hi @tim wilkinson

Unfortunately changing the default language on your server won't change the field name of 'Epic Color'. This is a common problem when migrating projects between Jira instances.

The quickest way (which you've mentioned above) is to unlock the field on your source instance > Rename it to match the destination instance > Lock it back > Run the Project Import.

The KB article you're after would be here - https://confluence.atlassian.com/jirakb/project-import-fails-with-custom-field-xxx-of-type-xxx-is-required-for-the-import-but-does-not-exist-425462621.html

There is an alternative way which is to hack the XML export but that can go wrong very quickly so I wouldn't recommend doing that.

tim wilkinson

Thanks - that seemed to work

unknown

Hmmm.... not working for me on my JIRA server version 8.2.1

I tried to follow the instructions here (https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html?_ga=2.117089089.652597362.1559829705-1777396627.1557175896) to unlock the field, but my H2 DB did not contain the tables in question (customfield,managedconfigurationitem, etc)

I also tried to create a new custom configuration field called "Epic Color", but could not create it with the "Color of Epic" type (the type is not listed when creating a new custom field)

Any suggestions as to how I can unlock, or create a new type, or any other suggestions?

Kevin Paulus

Also not working for me: I am able to update the managed field to false, and I then have the ability to edit the field name, however the field name remains unchanged except in the field edit screen. SO.....I am now in the position of telling a customer that there is a fatal error and we will have to spend additional hours manually updating their source files.

Rajat_7joxew

Yes, we can edit the field but the update has no effect.

This used to work for us in Jira 8.5 but now after upgrading to 8.20.1, this doesnt seem to be working.

Kevin Paulus

We wound up cloning our production environment & database (the source) to the developer server then deleting ALL 400+ project spaces from the developer site. This then made the developer site an exact replication of the source instance. After that, importing a single project from our production site back-up file went without issue and we are now able to provide an xml file of the single project without exposing the data from every other project to unauthorized parties. It took several weeks to do this because we have limitations of staffing & budgets as well as routine operations that can't be sidestepped.
Wouldn't it be great if there were a way to import the missing global elements first so the project import does not crash & burn because of innocuous or other meaningless discrepancies? Seriously; why should a spelling variation create hundreds of hours of workaround efforts? Further question: Why can't a Jira project XML files be generated for export the same way it is done in Confluence?

Mattias Vannergård_q98i2f

We have the same problem here. Even new instances created with English (United States) get the "Epic Colour" field, and an older English (United States)-Jira exports "Epic Color".

Tom Gee_to9qxu

You can also change the spelling of Epic Colour to Epic Color by editing entities.xml in the zipped backup file with VIM under Linux. (There may be multiple occurrences.)

Narasimha Tunuguntla

I was able to fix it by doing following:

1) Unlock the field

2) Custom fields -> Action (...) > Translate

and clear the translation

Juliman Gea

This way is working for me (v.9.6.0). Thank you

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

import