+1 really frustrating not fixed in Cloud

Hi Team , Is this fix available for Jira data center Version Atlassian Jira Project Management Software (v8.20.1) we are currently facing an issue with the same 

The Cloud version has a separate project, but the related ticket (if it exists) isn't linked here

+1 not fixed in cloud

+1 still not fixed in Jira Cloud (Team-managed project)

+1 not fixed in Jira Cloud (Team-managed project)

This is not fixed on Jira Cloud.

+1 on the not fixed in cloud

I can confirm it is not fixed.

This is not fixed and is still an issue in cloud version

Same here, my epics have Epic Status = Done, Resolution = Done, Status = Done, they still show in the dropdown.

Still happening to me with Epics that have Epic Status set to Done, and resolution set to fixed. Seems to only pull in epics from same project.

For everyone still experiencing this issue, check if your epics have a hidden field "Epic status" in addition to the normal "Status" field. If so, you need to make this field show up on the issue page, then change the "Epic status" to "Done" as well.

choosing epic:

but epic is closed with status done:

working with Jira Cloud

@andy nguyen, yes, thanks a lot - it works now! =)

Thanks ecw,

Have you managed to make it work, kirill.romanov960893118?

The important status is the "Epic Status" - you can set that one from the Backlog's Epic view (click the arrow, "Mark as Done")
https://prnt.sc/l224cl

UPD: https://prnt.sc/l21ld8

can you explain please what's difference between Status & Epic Status? what happened?

Can you also include the Field "Epic Status" in that list?

Hi!

Dear Atlassian teammates, I'm kindly inform you that current issue is still reproducing on Cloud version however 2015-11-30 Cloud, Available in JIRA Software Cloud set in the fixversion of the ticket.

Please find the screenshots by links http://prntscr.com/l21fd7 & http://prntscr.com/l21fvu

As you can see all of suggested epics for ticket are closed.

Please come back again and figure out with that issue as far as you can.

Thanks!

We just upgraded from v7.7.0#77001-sha1:3be3151 to v7.12.1#712002-sha1:609a505 and this still works as expected. No regression here.

I'm kinda assuming that it is likely as vdung suggested: Epics are "Closed" as ticket but not marked as "Done" from one of the boards.

still reproduces on Cloud

Hey samer.odeh,

I can't reproduce the issue in JIRA 7.12.0. So it doesn't seem to be a regression to me.

Just a quick check, how do you define Closed Epics? Do you base on the Status field or the Epic Status field? If it's a Scrum board, do the "Closed Epics" appear on the Epics panel? You may want to refer to Managing epics in a Scrum project.

FYI, an Epic is considered Done when its Epic Status is Done. If the Status of an Epic is Closed, but its Epic Status is still To Do, whereby it appears on the Epics panel in Scrum board (as well as Kanban backlog if you enable it), it's not Done and will show up in the Epic Link field.

Sounds a bit like a regression?
We've got an update scheduled soon-ish, since we skipped a few due to ongoing projects; but we might hold that off a little if this turns out to be the case.

we are running Jira Cloud and facing the same issue

Thanks Emanuel,

We are running  Jira internally (v7.11.0#711000) on Windows, when creating a new JIRA Issue and wanting to connect it to an EPIC, Closed EPICS pop up, even though the filter “Show done epics” is not selected

We're on v7.7.0#77001-sha1:3be3151 (Server, on-premise hosted on Linux, Core+Software enabled) and it works as expected. "Done" Epics only show up when I enable the "Show done epics" checkbox on the popup.

Do you happen to have some steps to reproduce (and perhaps an exact version number)? I simply scrolled to the top, hit "Create", then scrolled to the "Epic Link" field and opened the popup.

I don't think this is resolved ... is it working for others ?

agree, this seems not be fixed or what I am doing wrong?

it's not fixed, why did it mark "Resolved"? - is still on our Jira Cloud environment:

epics are in the "Closed" status and with "Done" resolution still appears in suggestion list

@mjopson

The issue with keying off of the Done epic status rather than workflow is that if you don't operate on scrum boards, you don't have the Epic panel to mark them as done. Realizing that workflows are configurable and keying off workflow statuses may be unreliable. Maybe expose the ability to mark as done somewhere else than just the backlog view of a scrum board?

Related issue which you might be interested in: https://jira.atlassian.com/browse/JSW-9222

Thanks. That makes sense now!

eduardo1002434486 - done in the context of epics currently refers to the epic status, not the workflow status. This is set on the epic in the Backlog epic panel item.
https://confluence.atlassian.com/jirasoftwarecloud/working-with-epics-764478086.html
https://confluence.atlassian.com/display/AGILE/Completing+an+Epic

Kind regards,
Martin
JIRA Software

I still see epics that are done in the dropdown, even with "Show done epics" unchecked. See visual below:

I'm running Jira 7.2

Thanks

This feature is now available for both JIRA Software Cloud and JIRA Software Server.
The server release version is 7.1.0, please see the server release notes for further details.

Kind regards,
Martin
JIRA Software

Do you have an update of when this will be available in Jira Server?
Thank you.
Andrew.

This feature is now available in JIRA Software Cloud and will be available for JIRA Software Server in a forthcoming release.
Kind regards,
Martin
JIRA Software

evangelos.vrocharis - deleted epics should not appear in the existing implementation. Could you please create a support ticket at https://support.atlassian.com to investigate further. That way we can provide you with support specific to your circumstances and with higher security.

Regards,
Martin
JIRA Software

Nice to see that this is being address but I'd like to point out that apparently even deleted Epics continue to show as suggestions. Is this also expected with the current behaviour?

Ignore my comment.

thank you for the change, it'll make epics much more usable.

Great job, Team! Thanks for doing this - it'll really make a difference in our day to day!

Thanks for watching, voting and commenting on this Suggestion.

As noted previously we are working on this currently. As an update, during implementation, we determined that the previous approach (comment-807824) could be improved upon. The updated approach is as follows.

Option to see done epics or not.
The addition of a checkbox to "Show done" epics in the menu. Default state will be unchecked (Done epics not shown).

Show open epics only
When "Show done" is unchecked the menu will show:
Top section (if results exist) named Suggestions
Open epics from the same project as the issue (listed alphanumerically)
Second section (if results exist) named All epics
Open epics from other projects (listed alphanumerically)

Show open and done epics
When "Show done" is checked the menu will show:
Top section (if results exist) named Suggestions
Open and Done epics from the same project as the issue (listed alphanumerically, meta-data indicated if done)
Second section (if results exist) named All epics
Open and Done epics from other projects (listed alphanumerically, meta-data indicated if done)

The menu will still include a type-ahead control to filter the list by typing.

This approach will assist with the primary goal of finding an open epic in the same project as the issue, but will still allow for the other secondary goals of finding open epics in other projects and done epics in both the same and other projects.

Kind regards
Martin
JIRA Software

Hi Martin,
Great to read that this evolution is being taken care for. All the best to you. And thanks for your consideration.
Regards,
Arnaud

arnaud5 - as noted in the last few days of comments, we're working on this at the moment. I'll update the Current Status above to indicate this.

Kind regards,
Martin
JIRA Software

Dear Atlassian, and dear JIRA bug GHS-9993 community, because this community has grown to ressemble to a piece of the world, I think we are clear on this, this is politely annoying us all.

Why should I still be able to assign tasks to epics which are already completed, it is complete non sense, Epic are defined to enforce the completion of sub-items which we want to see bloom. Once the Epic is completed, it is completed then... I will only want to know about it through the classic search issues capability, if I may ever want to ressurect it with a reopening.

Please Atlassian, fix that one before Christmas... It would make our life easier in 2016.

Keep the good work up! And all the best

Arnaud

The proposed design sounds great to me. I recognize the need to be able to add stories to completed epics, I often do retroactive cleanups like this. If the closed epics are flagged in the way Martin illustrates and sorted to the bottom then that's good enough for me.

Just for the sake of discussion, JIRA has a precedent for this kind of behaviour: archiving project versions. I would be equally supportive of having epics follow exactly the model that versions do: after you archive them they become invisible and you can't assign or unassign from them until they're unarchived. (I will admit that I've been annoyed at various points when I have to go and unarchive a version just to do some retroactive cleanup, but I recognize the tradeoffs.)

It seems like you're weakening support for the 80% requirement to support an edge case. If people need to assign items to closed Epics, can't they just reopen it while doing that unusual operation. I've certainly done that operation, but I don't need it to be easy. I need the Epic dropdown to only list valid epics. I think a major requirement is preventing people from accidentally assigning issues to closed epics.

Sounds good to me, thanks for clarifying!

ecw, ziko - we plan to add done to the meta data after the epic's name e.g.
Ben Hur (ABC-123 • Done)

A list of filtered epics could therefore look like the following:
typeahead of Ben
Bendigo (ABC-22)
Benjamin (ABC-11)
Ben Hur (ABC-123 • Done)

charlie5 - that's right, if we don't show the done epics then there is no place to update issues afterwards. It is a secondary case, but we still need to allow for this. By changing the order to always show matches for open epics first the done epics will only appear when the list is filtered significantly.

+ jlambert - At this point epics are treated differently to other issue types in JIRA Software, we only hide them in the epic panel when marked as done - not when the workflow changes. This is something we will look to improve in the future and we would need to do this consistently throughout.

pnm_erik - with the new order done epics will only be seen when the list is filtered significantly.

Kind regards,
Martin
JIRA Software

An Epic is more like a Release, you use it and it "goes away" (when the fixVersion is marked released, and then archived). Epics are larger than releases, but should behave the same way. It's difficult to explain to a team when they assign something to a completed Epic why it falls between the cracks. If an Epic is marked done and closed, it shouldn't be appearing in a users view, just like I wouldn't want them assigning something to a release that happened last year.

Please reconsider letting admins hide and really close Epics. Please.

@Martin and Atlassian,
Thank you for addressing this issue. Jira is an indispensable software ops tool, and this was one of the most irkful issues. Could you clarify this phrase in your comment:
> The done epics will be identified in the list

If it is as @Emanuel describes (hopes for) then it would be very welcome.

I don't know what the use case is for allowing people to add new items to 'done' epics, is it to support retroactive organization? Adding issues that should have been in an epic after the fact?

How about at least excluding Closed epics?

This sounds like good news, Martin, thanks!

Any chance you could include a small indicator for "Done" Epics? Currently, we workaround this issue by changing the Epic Name after closing by prepending the string "[DONE]". Something similar would make it easier to distinguish than just going by sorting (like a Prefix, different Icon, different Font/Style, lighter Color, the possibilities are endless )

Thanks for watching, commenting and voting on this issue.
The team is currently working on this item and we'll update this issue when a release date or version is known.

The implementation will still show done epics in the menu since there is a valid use case for them to be present but will prioritise epics which are open. In practice this should mean that done epics are only visible in the dropdown when the list is filtered to just a few remaining epics i.e. using the type-ahead control, and the done epics will be shown after all open epics that match. The done epics will be identified in the list to avoid assigning to them in error.

The list of epics will be prioritised by the following:

1. Open epics from the same project as the issue (listed alphanumerically)
2. Open epics from project history (includes other projects in recent board(s)) (listed alphanumerically)
3. Open epics from other projects (listed alphanumerically)
4. Done epics from the same project as the issue (listed alphanumerically)
5. Done epics from project history (includes other projects in recent board(s)) (listed alphanumerically)
6. Done epics from other projects (listed alphanumerically)

Note that only the first part of the list is shown, then the list is filtered based on the type-ahead control.

Kind regards,
Martin
JIRA Software

now i´m shure: atlassian don´t work with epics. that´s why this bug in not fixed yet
.... or ....
atlassian work extreme slowly - they have only open epics and the bug isn´t noticed

mhhhh.....what do you think?

I have 460 epics in my system. The change this is fueling my search for JIRA Agile replacements.

It seems to be more important to confuse Users with Reorganizing Product-Structure etc. instead of talking care of their daily needs...

Are you guys planning to fix this request anytime soon?

This is very frustrating, we have 100s of epics across a number of projects and the drop list was showing them ALL. Our current practice is to change the issue type from 'Epic' to 'Story' when closing an epic, which is less than ideal.

We need this fixed asap. It is hard to find the right epics when they are still shown on the drop down list.

We have a large number of closed epics and the team finds it very confusing that they are available to assign to newly created stories. Vote +1 to fix this one.

This produces a huge amount of confusion among the team because Epic information on the Backlog is different than Epics in the Epic Link dropdown. If they edit a story/bug/etc. and done/closed Epics show up in the Epic Link they don't know what to choose because the Epics aren't showing up on the Backlog (on the left). Epics are supposed to simplify the process but it is so wonky we just can't use the feature nor reports. It is really a shame - to fix the discrepancy we have to delete old closed Epics (or create a new fake type 'Epic Old' for example) which then ruins the reports. We lose the consistency of the Epic container. Please fix.

Agreed, we haven't grown within JIRA to the point where this is a huge issue yet, but it doesn't take too much foresight to see it coming soon. +1 for an admin setting: "Hide Closed Epics Within the Suggested Epics Dropdown". Or just remove them entirely without the setting.

It baffles me that this has to be a bug ticket at all and that after 2 years this still unresolved.
Please fix this, any team of reasonable size has so many of epics within a couple of months that searching for them in the dropdown becomes annoying.
This is basic functionality IMHO.

We have a similar problem.
We want to create an issue and assign it to an epic. I can see epics in the Dropdown-List "Epic Link" for which I do not have write permissions. I only have read permissions.
If I created the issue I don't get an error message and the issue isn't assigned to the epic.

To avoid mistakes the dropdown list should not display epics for which you do not have write permissions.

@jlieberman1: the only "workaround" I know of is changing the "Type" from Epic to something else. Sucks. BTW, I noticed that the "pse-request" Label was added to this ticket, so that gives me some hope that this will actually be addressed! (Since I assume "pse" means "professional support engineering" or some such thing).

I have not found a workaround. I wish I did...

Atlassian, please fix !!!

+100! We have over 100 Epics and growing just for one project (we have multiple projects, so that just . Over half of them are DONE. I should not be seeing these in my Epic Link dropdown. I'm growing tired of having to fix the link for the developers who accidentally choose the wrong (closed) one.

Has anyone come across a workaround??

+1 This quickly becomes unworkable if you use Epics with multiple projects. Small issue, large impact.

+1 In addition. What sense does it make, to have a parallell Issue-State-System for Epics? Either an Epic is done or not, why are they in parallel handled by the "usual" workflow?

+1 to what Emanuel Wlaschitz just said.. this is a rather serious issues for us. When you work with bigger systems, this can be really serious if you cant rely on issues appearing in the right places.

+1

+1 Please fix this.

++

+1

We just hit an actual problem with this. One of the closed Epics (actually: closed for a year!) was being used when new issues related to that topic were created. The issues did not show up in Plan view when filtering based on the existing epics, nor when filtering with "Issues not in any epic". We only caught this because I noticed there was an issue still to be resolved before the next release, but I couldn't find it while checking the epics that were supposed to track those.

At this point, we do not know how many more issues share this fate, especially since there is no way to write a JQL query to find those issues. IMO this must be treated as a Bug (as the linked GHS-11362 tried to do) or otherwise we might end up forgetting/losing track of issues that may have a contract related and need to make a certain deadline.

+1

We would need this also. I see no reason why I would want to ever see a done Epic in this dropdown.

+1

+1 - its a real pain for me to keep our backlog clean this way, as ticket reporters keep assigning issues to closed epics

+1. It seems like if you want to support an "On Hold" epic that would be separate from displaying all epics into perpetuity.

+1

+1 This is a pain, and makes the backlog maintenance a real pain for projects which have been living for quite a while. If it's closed/done, then it's should not be available from the dropdown, if you want to repoen it, then just go into the search issue page.

+1

I cannot agree with Toms comment either. I mark Epics as done when they're done; and that should be final. This also ties into the other issue that Epic "Done" and Issue "Closed" are not the same, which usually throws some people off when they first manage an Epic.

+1 I want to empower my entire team to write issues. Yet I am having to control the epics field, because they often assign issues to closed epics! I've had to resort to prefixing a tilde ~ to the beginning of every closed epic just to visualize that they are closed. What a waste of valuable time.

+1 This is making epic links very hard to use for us.

+1 This feature is really needed. There are so many other epics with similar names that are already closed and marked as done and still visible, that i can't really select new epics without knowing the issue number.

+1 for me too, this is a bug! We are using epcis for our weekly bugfix-updates within sprint - so the list is getting longer and longer.

+1 Please implement this feature!

Yaaah... I sincerely hope this request is addressed at some point. I have to change the "issue type" of my Epics to something else (e.g., Task) to "solve" this behavior. The first response from Atlassian was disappointing and I believe actually provides a strong argument for implementing this feature:

• "There are valid use cases why in some circumstances you'd want those to still show up - for example, you can close an epic temporarily while it's not being worked on, and still be able to map new issues against it."

So the argument's premise is: "people sometimes close epics and then want to reopen them."

That is certainly true. But since we don't have an option to hide the epic from the "Epic Link" field, and since it is unacceptable to include closed epics in the tab-completion for the Epic Links field, I'm going to have to either delete my Epic ticket, or change the type of it. And then what happens if I need to re-open the Epic? I presume you cannot easily resuscitate it with all of the linked issues intact, so I'd have to painstakingly recreate the original Epic, or just create a new one.

+1 This is not a feature request, it is a bug. The poor handling of epics (can't schedule in a sprint, can't control what you see in the drop-down, can't easily manage status outside of plan board) should be an embarrassment to the JIRA Agile team. Resolving this should be the least of what the team does to make epics a first-class citizen.

+1 We do realy need this feature implemented!

+1 again for fixing this, or having Tom Kotecki [Atlassian] provide the required link / instruction on how to manage epic link dropdown.

+1 for fixing or at least provide a possibility to configure what kind of epics should be displayed.

+ 1 for fixing this issue. This is a royal pain. On our team people keep accidentally choosing closed Epics for issues, and some poor sod (i.e. me) has to clean them up and assign them to the right ones. How can this not be a bug? Issues don't even show on the Plan board if they are assigned to a closed epic, unless you choose "All Issues". This is frequently resulting in items getting lost.

Would really like the ability to only show epics that are related to the project you enter.

I agree with the comments above. I am a certified project manager and have been working with Jira for years. This "feature" leads to misunderstandings and mistakes when working with epics, so it should be changed or removed.

Agreed. Showing closed Epics in the Epic Link drop-down is causing errors and is is a source of frustration for users. What about pegging drop-down list visibility to the Epic Status field value, specifically "Done"?

Another possible solution would be providing the option to archive an epic. This is how Atlassian implements versions. You can add something to a released version but not to an archived one (and archived ones no longer show in autocomplete anywhere). Allowing the list to grow indefinitely is proving challenging so hopefully providing some solution here will be reconsidered.

+1 as well.

The wrong epics are getting linked from different versions causing us to lose stories/confusion. If something is marked as done/closed...then it should be done. It seems to me you're trying to hold on the current behavior to solve an edge case, not standard expected behavior.