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

[Daniel Wong · Accepted solution]

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

[Weston Dyer]

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?

[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

[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]

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]

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]

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.)