How to Fix Duplicate Epic Color Fields in Jira After Project Import
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
After importing projects from another Jira instance using Configuration Manager for Jira plugin, we could observe 2 fields for the Epic Color: One using the UK-English format "Epic Colour", the other using the US-English format "Epic Color".
This KB article provides changes that are out of the scope of Atlassian Support and, therefore, is provided as-is. The steps are only meant to fix problems within Jira Software, and not necessarily to be used for any locked fields. Consult with Atlassian support before following the steps listed here. This step can introduce unintended side effects in Jira (such as the inability to pre-populate fields during Issue creation) if unexpected changes are made to default fields, such as adding Translation Text to fields that do not permit this by default.
As with all recommendations made by Premier Support, we suggest following best practices for change management and evaluating these settings in a test/staging environment prior to rolling out any changes to a production environment. You must test and validate these changes to ensure that they will function well within your infrastructure before considering them for production deployment.
Diagnosis
1. Check which is the default Epic Colour used by the Jira instance. The propertyvalue column will contain the Custom Field Id of the field:
SELECT * FROM "PROPERTYENTRY" pe
join propertynumber pn on pe.id=pn.id
where pe.property_key = 'GreenHopper.EpicColor.Default.customfield.id'2. Check which are the custom field Ids used by both fields.
select * from customfield where customfieldsearcherkey='com.pyxis.greenhopper.jira:gh-epic-color-searcher'ID | CFKEY | CUSTOMFIELDTYPEKEY | CUSTOMFIELDSEARCHERKEY | CFNAME | DESCRIPTION | DEFAULTVALUE | FIELDTYPE | PROJECT | ISSUETYPE | ISSUESWITHVALUE | LASTVALUEUPDATE |
10106 |
| com.pyxis.greenhopper.jira:gh-epic-color | com.pyxis.greenhopper.jira:gh-epic-color-searcher | Epic Color | Epic Colour field for Jira Software use only. |
|
|
|
| 3 | 2022-07-05 12:22:57.035 |
10200 |
| com.pyxis.greenhopper.jira:gh-epic-color | com.pyxis.greenhopper.jira:gh-epic-color-searcher | Epic Colour | Epic Colour field for Jira Software use only. |
|
|
|
|
| 2022-07-05 17:07:12.317 |
3. Identify the extension of the problem. How many issues are using each field returned by the previous query? For instance, ID 10106 and 10200:
select * from customfieldvalue cv join jiraissue j on cv.issue = j.id WHERE customfield ='10106'
select * from customfieldvalue cv join jiraissue j on cv.issue = j.id WHERE customfield ='10200'Cause
Different languages were being used on the Jira instances. During the import, the difference between "Epic Color" and "Epic Colour" caused Jira to create a new field.
Solution
1. If the field that should remain is "Epic Color":
Use the Issue Navigator to search for the issues, for the same color, for instance, using "Epic Colour" = 'ghx-label-1''
Bulk edit the issues copying the value from "Epic Colour" to "Epic Color"
Clean up "Epic Colour" content
Repeat these steps for each value of color, until all the "Epic Colour" content was copied to "Epic Color".
2. Unlock the field "Epic Colour" following the instructions from Unlock a locked Jira Software custom field
3. Delete the Custom Field "Epic Colour" :
At the Admin > Issues > Custom Field
Go to the actions menu '...' on the "Epic Colour" row and select the delete option
Note: When running this bulk operation on an environment using Reverse Proxy, it might occur a timeout if there are too many issues related to the custom field.
Reference: Delete Custom field options times out due to very large customfieldvalue table . Possible workarounds:
Access the node directly instead of using the reverse proxy URL;
Or Increasing the Reverse Proxy timeout value to let the call finish.
Was this helpful?