Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,369,101
Community Members
 
Community Events
168
Community Groups

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

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

4 answers

1 accepted

2 votes
Answer accepted

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.

Thanks - that seemed to work

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?

Like ivz-viktor likes this

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.  

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.

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?

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

I was able to fix it by doing following:

1) Unlock the field 

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

and clear the translation

 

Translate.png

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

Suggest an answer

Log in or Sign up to answer