This is not resolved. Please reopen. We need the option to restrict epics on a per-project basis. Still an issue in Jira v8.2.1

Same here, I would like to be able to limit Epic selection on a per-project basis only.

I completely agree. This is not fixed I just got reported by one of our team members even today again. We are using Jira v8.1.0.

I would definitely agree this is not fixed in what I am seeing in 7.6 and 7.13.5.  I work at a Fortune 50 company with a massive Jira deployment.  There are well over 1,000 projects.  The epic link field is essentially unusable.  As an Epic exists structurally/hierarchically within a project, it should not be used across projects (IMO).

Even if you disagree with my opinion, there are clearly enough other people on this ticket and others that share it.  Therefore, I ask that you make it a project level setting to limit epics to just within this project, and then let people choose if they want to select epics from other projects or not.  Additionally the names of some epics are extremely similar.  as each project might have the same epic (Security Auditing, or Complete End Of Year Processes).  I want to make sure the items are linking to the Epic for this particular project only.

 I honestly don't think this is resolved.... nor do all the others trying to figure this out. We may be poor users of Jira, but if that is the case, then educate us or fix this!!!

“if an Epic issue type is Invalid,Closed, Done, Resolved” then an issue cannot be added to that Epic

The issue we have run into is, when folks might not pay close attention, they may select an epic that is closed/invalid  and put a new story/bug in it.

We’d like to prevent this user behavior if possible. It was proposed we might see if a rule could do that.

•  Modify the drop down for Epic Link in a Story – can we filter out Closed, Done, Invalid, Resolved Epics from this drop down?
• Can a rule be implemented that would prevent a Story from linking to an Epic if that Epic is Invalid or Closed?

@marten oh, thanks for info, I had no idea about this. Seems quite counter-intuitive to me. I'll make necessary changes in workflows. 

To implement your recommendation properly, would I need a Epic only Workflow? i.e. what if my Epics and Stories share the same Workflow?

@Nikola, @Xavier: The "Show done epics" is not connected to the Status Done, but to the customfield "Epic Status", which has a separate "Done" marker. So for best practice you add a postfunction in your Epic workflow to set the "Epic Status" field to "Done" when you resolve Epics. Unfortunately you need an app for this, e.g. Misc Workflow Extensions.

@Nicola Bornovà : I agree with you. However, I don't know which criteria is used as filter in "Show done epics". It could be "Resolution = Done". But I can't check it, because in either cases (with "Show done epics" checked or unchecked), I have epics in Open status, and Resolution field with "Unresolved". It's a mistery to me.

Why is the filter for "Show done epics" connected to status and not to resolution? This doesn't make any sense - we have many Epic workflows with different final status than Done (like Closed, Resolved, Acknowledged etc. etc.). This checkbox should definitely be connected to Resolution, not to Status. (and to be clear - it should be switch between Unresolved or any resolved Resolution)

I found in our Jira version,  when I select in Epic link field, Epics of current project are displayed on top of the list in "Suggestions" section. I think that it's rather enough for me. This solution meets the need of who want a limited choices and in the same time that  who wish to have larger choices.

Still showing on our cloud version. Can we get a response on this please guys?

Hi. We still have this issue on Cloud too. Please reopen this request ! 

Still a huge issue, please fix. 

NOT FIXED (since 2013 and going.....)

Still showing ALL the Epics from ALL the Projects !!!!

Shame on you Atlassian !!!

It's not a Suggestion it's a BUG !!! a terrible one !!!

After commenting above 7 months ago, I just now took another shot at articulating this story as JSWSERVER-16692, which for me too remains unresolved. I dunno, maybe we stand a better chance at getting a "new" issue resolved, than opening a resolved issue.

The same issue. Fix please ASAP.

This post and comments began Jan 2014. Hard to believe no one at Atlassian has solutioned this issue.. do you not see the posts or understand how frustrating and non-efficient it is to scroll through a long list of Epics every time stories are created. Jira is supposed to automate and streamline.. make it easy to manage Sprints and stories.. the long Epic list is crazy.. seriously! My company finally gave up and went with a component list instead. Fix the problem! PLEASE!!!

NOT FIXED !!!!!!!!!!!!!!!, still showing ALL the Epics from ALL the Projects !!!!

Still not fixed. All the epics from all projects are listed in picklist for current project. Frustrating to scroll through a long list every time we create a new user story. Any updates or eta on when this issue will be resolved?

Is this issue going to be fixed? the ticket status is resolved and the issue is still happening with version 7.2.x

Why on the Earth is this still an issue? It makes Jira Cloud so unusable and adds security issues. Can it be fixed ASAP?

That is a know issue in Jira Cloud and Atlassian has no resolution for it when I checked about 3 months ago.

Epic Links for All projects are still showing up for us as well.  

Epics Links for all projects are still all showing for me with  Atlassian JIRA Project Management Software v7.3.7.  Please fix this, no need to see Epic links from other projects.

Not fixed in Jira Cloud either.

Still not fixed for us either (Jira 7.3). For Example when creating a new issue you can link this issue to every epic you are allowed to see overall. Thats not applicable at all! Please fix asap.

Make the epic link smart to only show the epic's from what the board filter is using. so for example if the board filter allow 4 projects, the epic link search should ONLY search across those 4 projects.  If the filter has only one project the search in the epic link will be only across that project.

This change must happen very soon.

Btw: I assume that if you don't have permissions to a project in the filter, you wouldn't see this project either.

We are running 7.3.8 version and the issue is still reproducible. Support, please reopen this ticket and fix. Thanks. 

For our company this is a data security issue. Our JIRA instance is used by different clients and its not acceptable that they see epics from projects where they don't have access to. If this issue will not be resolved we unfortunately can't use JIRA anymore.

Agreed. This is really confusing, as I'm getting ready to roll out this software to my team. I'm going to have to explain to not cross epics when assigning issues. 

Adding to the pile: the epic link field should show only the project's epics, not global epics.

I agree too, I didn't see any fix for this.

Agree, this is creating a huge mess for our team. I may not even have the same client on projects and the epics are showing for all projects. Clients are choosing epics from other projects. Should Epics be viewed as global?

Yea, this still exists 

I agree, I don't see this as solved.

Same problem for me 

This suggestion ticket may be titled "The Epic Link field list Epics from all the projects instead of the current one", but Atlassian did not exactly address that as it was intended. Instead, they added a “Suggestions” section that lists the epics for that particular project. Thus, all epics from other projects (that you have permission to) are still listed below that. Not ideal at all.

Hi, has this been resolved?  I'm still seeing all epics from all projects opposed to a single project's assigned epics. 

It would be nice to hide All other epics by default then allow users to click to Show all other epics.
This would prevent users from accidentally clicking epic names from other projects unless they know exacly what they are doing.

Me too.

I am also facing the same issue.

Hi Kim,

If you are still experiencing the issue, please raise a support request at https://support.atlassian.com

Cheers,
Ignat
JIRA Bugmaster.

I see that there the epics from the current project are displayed then there is a separator and then all epics from all projects are displayed.  How do I remove that second part of the drop down?

Either I am still having this bug or I did not configure permissions correctly. Can you give me directions how to configure Jira so the projects can not share any Epics between those? I am using Jira Cloud Code.

I still see epics from other projects in my Cloud Instance.

Our Use Case is that we link to Epics that are in another project. Is there a way to get epics from another project in the dropdown (e.g. a project setting)? Perhaps show all matching epics if there are fewer than 10? Or a checkbox that you can click on that displays all results (like the closed epics checkbox)?

prabier7658304 - I've fixed the links up now, thanks.

prabier7658304 - as per my previous comment, we have implemented a solution which addresses the required use-cases and is optimised for the main use-case of locating an open epic from the same project, the comment above details the implementation.

Kind regards,
Martin
JIRA Software

We have installed the version 7.1.0, I read the server release notes and I still see all the Epics from all projects when I create a new issue…
What am I missing?

We have implemented a solution which addresses the required use-cases and is optimised for the main use-case of locating an open epic from the same project, see comment above for more on the implementation.

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

edit: fixed URL

krao1 - not yet, it will be available in the next major release of JIRA Software for server.
Kind regards,
Martin
JIRA Software

Is this available in the Jira software for server install ?

heather.walden1362015929 - this should be visible in your Cloud instance now.
Sprint selection is not covered in this issue, please see https://jira.atlassian.com/browse/GHS-11814

Kind regards,
Martin
JIRA Software

I am not seeing this updated in our cloud yet and I also see this issue when selecting a sprint. Separate issue or same?

Thanks Martin! This is very helpful and it's ALWAYS great to see issues that impact a lot of people getting fixed! I know we all appreciate it.

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

ivan.zaguirre1499704428 - it's not shipped yet, please continue to watch this issue for updates of the fix version for JIRA Software Cloud and JIRA Software Server. I will also update the Current Status field when it's released.
The release to JIRA Software Cloud is expected soon.

Kind regards
Martin
JIRA Software

Martin,
I've been checking my company JIRA version and it's 7.0

But I can't see the solution that you explained on comment-820661. Why?

zahira.melendez - the type-ahead currently limits the list to 10 items as you note. We will look into increasing the length of this list balancing performance and usability concerns.

Kind regards,
Martin
JIRA Software

Will the type-ahead display all the epics? Currently in v6.3.12 the type-ahead limits the list to 10. For example, I have a project that has 21 epics. When I type-ahead the project key "SR", the drop down displays 10 of those epics. If my epic is not listed and I don't remember the name of the epic, how do I get it? Displaying all the matches or having a "View all" link like the Component field is beneficial.

Thanks for addressing this issue.

huuuze, this will be available for a future release of JIRA Software only (so 7.x).

Versions of JIRA before 7 (using JIRA Agile) will not get this update, an upgrade to a newer version would be required.

No new versions of JIRA Agile will be released, the only exception would be in case of a security fix. Only critical security issues are backported as per the guidelines set out in the security policy at https://www.atlassian.com/security/secpol with further information at https://confluence.atlassian.com/support/atlassian-patch-policy-201852333.html

Kind regards
Martin
JIRA Software

@Martin, I agree with Cody – this solution is an improvement.

Will the solution to this problem be applied to the 6.x releases or only 7.x?

@Martin - Your proposed solution is a definite improvement. Thanks!

rob.geraedts - I have explained comment-820661 why this is possible and how it may be used. The shortest summary is that Agile boards show all epics returned by the board's filter and any can be used as the team sees fit. Cross-project or multiple project boards are one common scenario.
More information about the boards is available at https://confluence.atlassian.com/display/JIRASOFTWARECLOUD/Creating+a+board

I've not been actively monitoring this issue so forgive me if I overlook something. I'm not getting the point regarding the Sprint board being able to show issues from more than one project.
If I create an issue, I first select a project to create it in. After selecting a project, I cannot understand how/why I should be able to attach the issue to an epic that is created in another project.

Consider Project A with Epic A and Project B with Epic B.
In my opinion I should never be able to create an issue X that is related to Project A and Epic B! This simply doesn't make sense to me.

Am I missing something?

Rob.

huuuze - The list should only contain epics from projects which the user has browse permissions. As noted above, if you believe this not to be the case please create a support ticket at https://support.atlassian.com . That way we can provide you with support specific to your circumstances and with higher security.

@Martin, and the "Other epics" section will not include Epics if the user does not have permissions in that project, correct?

huuuze - Correct, relative to the issue being edited. Effectively Suggestions would be this project, Other epics would be other projects.
For a project with many open epics the Suggestions section would probably be the whole list at first, then on typing as the list is filtered it would depend on the matching. But the segregation would persist as seen in the 3rd image in my comment above.

@Martin, to be clear, the "Suggestions" section will only llist Epics associated with the ticket's project, correct?

rob.geraedts, karen.e.rogalski, huuuze - there are no known security issues with the epic link field, if a user does not have view permissions for a project then they will not see the epics for that project. If you believe this not to be the case please create a support ticket at https://support.atlassian.com . That way we can provide you with support specific to your circumstances and with higher security.

Kind regards
Martin
JIRA Software

I would like to clarify here that it is not a bug that epics outside of the current project can be used for issue assignment. Agile boards are highly configurable and support multiple projects. It is possible to use epics from one or more projects in the epic panel and assign issues from one or more projects to them - they do not need to be from the same project. This allows management and reporting of epics in single and cross-project cases i.e. progress on an epic with issues from multiple projects can be viewed on an epic report or epic burndown.

The Agile boards, which are the heart of Software projects, support these assignment options and so do the menus used in other contexts to edit the epic link for issues, including the menu in the Quick Create and Quick Edit dialogs and the menu in the View Issue page.

We understand that assignment in these additional contexts is problematic for many of you, the current implementation makes it difficult to identify an epic's project and also if the epic is still open or has been marked as done. We are working to improve this and I have recently updated a related Suggestion GHS-9993 with the solution we are working on which I will post here too.

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.

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.

Kind regards
Martin
JIRA Software

@Brian, same problem can happen if you have security on issue level permission.

@Fabrizio, that makes sense if those projects are included in the same Agile board. However, this makes no sense as a default behavior. It also overrides the security settings within the project, allowing users to see the Epic name even though they don't have view permissions in that project.

It's a bug and, frankly, should be an easy one to fix from Atlassian's perspective. Add a filter to the Epic Link dropdown that determines if that epic's project is in the Agile board's filter and if security permissions would allow that user to view it.

I encourage everyone to vote this issue up.

for me and a lot of our contact, this is good as it is.
Usually we have different project that store epic that has to be shared in different software project

Not a Suggestion, this is a Bug for my large organization. Re-classify it as a Bug and fix it Atlassian!

She did when she created it:

https://jira.atlassian.com/browse/GHS-12611

But Atlassian closed it, declaring it a duplicate of this "Suggestion".

Hey Sheila,

that sounds very disappointing! What's wrong with these guys?

I can't imagine Atlassian is actually using JIRA in-house for more than one project if they don't see this as a massive bug. I suppose if they fire up an instance of JIRA for each project, they would never encounter this bug, but those of us who have to pay for JIRA instances can't possibly create a single JIRA instance for each project. I suppose it's possible Atlassian uses other issue tracking software internally, but that seems hard to imagine.

I actually re-created it as a bug and Atlassian closed it as a duplicate of this issue.

Hey Atlassian, this is NOT a suggestion, this is a BUG! Please fix this ASAP!

Please Atlassian, you really need to act here!

It's unfortunate that the workflow for this issue follows a simple, "Open > Closed" format. I'd like to see this issue moved to "In Progress" so we know Atlassian is taking it seriously.

We need a response Atlassian

I just reproduced this in my current project. Annoying!

since it should be considered a Major bug from the beginning

How is it that Atlassian receives a bug report on an issue that's two years old and now decides to consider it major?

Opened up a separate ticket with Atlassian support. According to them

"This issue is being tracked here now, since it should be considered a Major bug from the beginning. There is no ETA yet to get it fixed, but please be sure that our developers and product manager are aware of this and will share their findings there soon."

Maybe the left and right hands aren't talking to each other?

I added this as a bug instead of a suggestion. I've read several threads where Atlassian has said that only the project selected will show but that is definitely not the case, so it's a bug. Please vote/watch here:
GHS-12611

I developed with JIRA in my business.
We bumped into this issue now (which already has 1 year anniversary)

It's not only one year old, it was posted more than two years ago

If you (Atlassian) may not fix this, because you see advantages in working with epics this way, so please provide a configuration parameter in the general configuration for that! Or maybe you can add an "epic range" attribute to the epic type, where everyone can decide if the single epic should be globally displayed or not.

This is not a suggestion, it's a very nasty bug that needs the staff's attention. I don't understand why this was not fixed since it was posted more than 1 year ago.

Why is this bug even there?

I can only re-iterate the sentiments expressed in the previous comments.

The Atlassian support strategy can be seen as "letting us customers down" somewhat with respect to this issue and others where the use community has heavily voted for a feature or bug fix.

I cannot believe such a basic, useful, and highly-requested feature is not included.

Atlassian, this is a huge pain-point for anyone using epics on multiple projects (which includes pretty much all of your intermediate to advanced users). Please stop ignoring this issue.

As others start to use this software outside of software development, they are creating crazy epics. This needs to be project based on the selection. 100 user license.

This is a Bug on your security functionality, fix ASAP. In a small software company, its a suggestion. In a corporate environment with dozens of application scrum teams, its a Bug.

Come on Atlassian. So much for security....

This is also very problematic for our company, we find ourselves opening two browsers so that we can find the epic in browser and create the ticket it another. Even if we know the name of the epic, usually multiple projects will have the same epic so the one for our project won't even show up in the list which is limited at 10 or 12. Would be nice if the Epic Link could have the ability to show only epics for the current project, with option to view all epics.