This bug workaround will primary benefit larger Jira instances with many Epics.
When creating bugs or feature requests, there is an Epic Link field letting you connect your new issue to an existing Epic.
Have you noticed that is showing rather a lot of Epics in the Epic Link drop-down? In fact, that it is showing Epics that are resolved, despite the
Show done epics checkbox being unchecked?
This is because the Epic Status field on those Epics is not in sync with reality. This happens when Epics are resolved through regular Jira issue screen, and not via a Board.
Jira renders closed/resolved issues as
striked out links. Closed issues also don't appear in the default "Open Issues" filter or "Created vs Resolved" portlet.
But Jira workflows are arbitrary:
- A Bug may transition from Open → In Progress → Resolved → Closed.
- A Task may go from Todo → In Progress → Done.
- A HR workflow might be Prospect → Interviewing → Hired.
How does Jira know that some statuses ("Closed", "Done", "Hired") mean the issue is finished, and can be rendered
Answer: it relies on the presence or absence of the
resolution field. To Jira, no resolution means 'open'. It's a hack, and leads to problems when workflow designers fail to set/unset
resolution in sync with the status, but it works. See https://confluence.atlassian.com/cloudkb/best-practices-on-using-the-resolution-field-968660796.html for discussion.
Then in ~2006 or so along came Greenhopper, a Jira plugin that added Epics and Agile Boards to Jira. Greenhopper also needed a way to identify done Epics, so they could be removed from the Backlog 'Epics' filter, and removed from the 'Epic Link' filter shown above.
For some reason, rather than rely on
resolution as a marker, Greenhopper added a new hidden custom field,
Epic Status, with hardcoded values
To Do ,
In Progress and
Done. This custom field needs to be kept in sync with the Status field on Epics.
Atlassian simply never implemented a way of syncing
Epic Status with
Status. They put a page in the docs saying how to modify the Epic workflow to achieve it, but nothing more. And thus Jira in the world has
Epic Link fields showing Epics that shouldn't be showing, as in the screenshot above.
Epic Status was a bad idea anyway, and Atlassian later implemented 'status categories' which achieve the same thing. There is a never-to-be-fixed bug suggesting Epic Status be removed in favour of status categories)
There are two parts to our fix:
1) Fix the existing problem
In Jira, if you run the JQL search:
issuetype=Epic and resolution is not empty and "Epic Status" is empty
you should get no results (all resolved Epics should have 'Epic Status' set).
If you get results, you need to click the top-right 'Edit' button in the search results, and bulk edit them to set the
Epic Status field to
After this bulk edit, try to create a bug, and find the Epic Link field. It should now correctly show only the really-open Epics.
2) Prevent the problem from recurring
Epic Status in sync with
Status one can used the Groovy listener, originally posted by at https://community.atlassian.com/t5/Jira-Software-questions/EPIC-Status-Vs-Status/qaq-p/728237, and replicated here for posterity:
As of (Jira 8.20.x) the code works with no modifications needed except customizing the custom field ID.