Summary

The Jira Software application comes out-of-the-box with only 1 Epic Status field. This field is locked, which means that its configuration cannot be changed, and it is normally impossible to create a 2nd Epic Status field.

As explained in the documentation Working with Epic Statuses, this field is used by different functionalities

• It is used to determine if an Epic should be displayed in the Epic Panel of a board. For example:
  • the Epic will be displayed if the Epic Status field is not set to the last option configured for this field (usually it is Done)
  • the Epic will not be displayed if the Epic Status field is set to the last option configured for this field (usually it is Done)
• It is used to determine is an Epic is completed or not. When clicking on the Mark as done button from an Epic, the Epic Status field is set to last option configured for this field (usually it is Done)

We have seen situations where, when issues are imported into Jira from another Jira instance using a 3rd party add-on such as Configuration Manager for Jira (CMJ), a duplicate Epic Status field might be automatically created, and the Jira Software might be automatically "reconfigured" to use that duplicate field instead of the original one. When that happens, the following issues might be observed:

• Epics that were completed closed before the import might show again in the Epic panel of boards
• The Mark as Done button will be available for these Epics, even though they have already been marked as done in the past

This KB article explains how to diagnose and fix this type of situation.

Environment

Jira Software Server/Data Center, version 8.0.0 and above.

Diagnosis

• The problem with the Epics occurred after importing Jira issues from an external Jira applications
• Epics that were marked as done in the past are showing again in the Epic panels of board
• When going to the page ⚙ > Issues > Custom Fields and searching for Epic Status, we can see 2 Epic Status fields (the original one, and a duplicate one which might be translated in a different language than English):
  
• When running the following SQL query, we can also see that there are 2 custom fields of type Epic Statuses, with different IDs:

  • Query:

    SELECT id,customfieldtypekey,cfname from customfield where customfieldtypekey = 'com.pyxis.greenhopper.jira:gh-epic-status';

  • Example of result:

    id | customfieldtypekey | cfname
    -------------------------------------------------------------------
    40326 | com.pyxis.greenhopper.jira:gh-epic-status | Epic Status
    16103 | com.pyxis.greenhopper.jira:gh-epic-status | Ãtat de l'épopée

• When running the following SQL query which is meant to identify which custom field ID the Jira Software functionality is using to determine the Status of Epics, we can see that instead of using the ID of the original Epic Status field (ID 40326 as per the SQL query above), it is instead pointing to the ID of the duplicate Epic Status field (ID 16103 of the SQL query above):

  • Query

    SELECT * FROM propertyentry LEFT JOIN propertynumber
    ON propertyentry.ID = propertynumber.ID
    WHERE property_key = 'GreenHopper.EpicStatus.Default.customfield.id'
    ORDER BY property_key ASC;

  • Example of Result (check the value of the the propertyvalue column, which is the last column and which is set to the duplicate Epic Status field ID 16103):

    id	entity_name	entity_id	property_key	propertytype	id	propertyvalue
    81978	GreenHopper.properties	1	GreenHopper.EpicStatus.Default.customfield.id	3	81978	16103

Cause

The exact reason why a duplicate Epic Status field was created and why Jira Software was configured to point to that duplicate is currently unclear. We suspect that something might have gone wrong during the import of issues from the external Jira application.

Since the Jira Software application is pointing to the duplicate Epic Status field, any feature that relies on that field will no longer behave as expected. For example, to decide if an Epic should show or not in a board, Jira Software will check the value of the duplicate Epic Status field for that Epic. If the duplicate field has no value for that Epic or is incorrectly set, the Epic will end up appearing in the Epic Panel of the board even though the value of the original Epic Status field was correctly set to Done.

Solution

To fix this issue, we need to reconfigure the Jira Software application to point to the ID of the original Epic Status Field, by directly manipulating the Jira Database.

Here are the steps:

1. Backup the Jira Database using the Native Database Tool
2. Schedule some maintenance window and shutdown the Jira application (or all the Jira nodes, in case of a Jira Data Center cluster)

3. Run the following SQL query and take note of the ID of the original Epic Status custom field. We will refer to it as <ORIGINAL_EPIC_STATUS_ID>:

   SELECT id,customfieldtypekey,cfname from customfield where customfieldtypekey = 'com.pyxis.greenhopper.jira:gh-epic-status';

   
   

   1. In the example of result below, the ID of the original field <ORIGINAL_EPIC_STATUS_ID> is 40326 (The ID of the duplicate field is 16103):

      id | customfieldtypekey | cfname
      -------------------------------------------------------------------
      40326 | com.pyxis.greenhopper.jira:gh-epic-status | Epic Status
      16103 | com.pyxis.greenhopper.jira:gh-epic-status | Ãtat de l'épopée

4. Run the following SQL query and confirm that the propertyvalue column is currently set to the wrong duplicate Epic Status field, and also take note of the value of the ID column. We will refer to it as <PROPERTY_NUMBER_ID>.

   SELECT * FROM propertyentry LEFT JOIN propertynumber
   ON propertyentry.ID = propertynumber.ID
   WHERE property_key = 'GreenHopper.EpicStatus.Default.customfield.id'
   ORDER BY property_key ASC;

   1. In the example of result below, <PROPERTY_NUMBER_ID> is 81978, and we can see that the propertyvalue column is incorrectly set to the duplicate Epic Status Field ID (16103):

      id	entity_name	entity_id	property_key	propertytype	id	propertyvalue
      81978	GreenHopper.properties	1	GreenHopper.EpicStatus.Default.customfield.id	3	81978	16103

5. Run the following UPDATE query by replacing <ORIGINAL_EPIC_STATUS_ID> and <PROPERTY_NUMBER_ID> with the values identified in the previous steps:

   update propertynumber set propertyvalue = <ORIGINAL_EPIC_STATUS_ID> where id = <PROPERTY_NUMBER_ID>;

   
   

   1. Example of UPDATE query, using the IDs found in the examples above. NOTE that these IDs will likely be different in your Jira instance! Please do not run the query below as it is, it is just an example:

      update propertynumber set propertyvalue = 40326 where id = 81978;

6. Start the Jira application (or each Jira node 1 by 1 in case of a Data Center cluster), and wait until the Jira application is accessible
7. Go to the page ⚙ > System > Indexing
8. Run a full Re-index.  This step is required, since the Epic Panel functionality (along with the Mark as done button) relies on indexes to be up to date
9. Verify that the issues with the Epics are now resolved