+1

+1

+1

+1

if only Atlassian would look at these comments and provide response ! Seems like a wishful thinking 

Very usefull request!

I have board based on Epic swimlines. There we see issues and subtasks.

Work is organized on priorities by Epic (top priority Epic is first on roadmap and first on the board).

If issue go out from current board (to another department for example) unclosed subtasks drops-down from first priority swimline to "Issues without Epic" at the bottom of the page. It's very-very unplesant behabiour.

Possible solutions:

• add "Epic link" to subtasks
• keep them under Epic swimline at least (regardless of the parent issue visibility)

+1

+1

Can you please review this ticket

+1

+1

+1

where do we go to upvote this? it really should be fixed, it was simple to do on server, but a pain on cloud.

Running into this issue with my team at Adobe. 

It's also a problem when the parent story of the sub-task is assigned to another user. So if we have quick filters by assignee their sub-tasks will just be floating in the "issues without epic" category.

This would be a very simple fix:

• Add the epic link field and default to inherit from parent

Is this a duplicate of JSWSERVER-11823 and  and JSWCLOUD-16752 and possibly others? I'm pretty sure if you add up all the voters from all these issues it would be a bit higher in priority?

This impacts our business severely, it's imaginable that a bug caught in 2014 still has not been fixed in 2021.  We have had to abandon the use of subtasks in many cases due to this.  

Ticket created: May 2014

Last Atlassian update: Oct 2019 - "we still know this is broken and have no plans to do anything about it"

It makes me wonder just how horribly broken your flagship software is when I can find such an obvious and significantly value-reducing bug within my first week of trialling Jira for our new company, and yet there are so many other priorities that it still isn't even seriously considered for fixing nearly 7 years later.

Is it a failure of code or management? The woeful performance of the web interface would suggest a horribly written and/or maintained code base. That said, what should essentially be a minor query fix taking this long to take seriously and still not even having an ETA for a fix suggests a dismal failure of management and/or a severe lack of respect for your customers.

Suffice to say we will not be moving forward with a paid Jira plan as a result of this.

Very disappointing to see that this will not be fixed soon. Makes the use of Epics irrelevant for our project, and at this point, we're considering dropping JIRA.

Our epic and parent tasks are assigned to PM, but sub-tasks are assigned to developers on a different board - that means that the developers can't use swimlanes at all, because the parent task is filtered from their board.

This also occurs if the parent ticket is not displayed on the board because it is in the Kanban backlog screen or if the parent ticket is marked complete so we have this orphaned tickets at the bottom of our board.

I might have found the issue.

If you use Epics as swimlanes on a kanban board and all issuestypes, like; Story, Task, etc.., are linked to a parent (Epic).

All seems fine even using quick filters and/or a specific user (myself).

The problem starts when sub-tasks are assigned to other people than the assignee of the parent task.

Then you get the strange result that those sub-tasks end up showing under "Issues without Epics"

I might have found the issue.

If you use Epics as swimlanes on a kanban board and all issuestypes, like; Story, Task, etc.., are linked to a parent (Epic).

All seems fine even using quick filters and/or a specific user (myself).

The problem starts when sub-tasks are assigned to other people than the assignee of the parent task.

Then you get the strange result that those sub-tasks end up showing under "Issues without Epics"

How is this not fixed? Makes the use of quick filters along with epics on the boards useless if you use subtasks.

very disappointing to see  it closed as well.  Removes transparency and is not visible in epic tracking 

My version of this bug is a bit different. We just adopted a new way of working. 

1. We have epics, as we always have, which we use as swim lanes
2. We create a ticket for an entire feature which is assigned to the product owner
3. We create subtasks on that ticket and assign them to whoever is doing the work.

Those sub tasks don't appear in an epic in the assigned people's boards. It's not because we've chosen to hide the parent issue, it's because the parent issue is assigned to someone else and so if any of the devs apply a filter to only see their work on the board, the sub-tasks appear without an epic.

Maybe you can reconsider? I can't imagine you think it is good that sub-tasks assigned to people other than the ticket assignee will appear without an epic.

I just want to weigh in with disappointment this isn't being resolved. This make tracking and stand-ups harder. 

This is inhibiting our use of subtasks & boards in Jira. Pawel Drygas, yes your decision is disappointing. Furthermore, transparency is something we should take for granted from a company as Atlassian, it's not something you should be expecting praise for.

This affects me greatly as well. I was so sure this was default behavior that I managed to get multiple teams to move to Jira, now I wish we did not. It makes the product more or less useless for us.

This should be fixed. It's annoying and completely messes with the project overview.

The problem was fixed when I switched from next gen to classic.

The same goes for us - totally messes the daily standups. Extremely annoying.

This bug totally ruined using of Quick Filters or Swimlanes... Please, repair it as soon as possible, thanks.

This is an issue for my teams

Very disappointing, this should be the default behavior. 

Exact same reasoning here. The point of this is to make standups easier by visualizing everyone's singular tasks under epics. This is broken currently.

The same goes for us - totally messes the daily standups. Extremely annoying.

Echoing the sentiment that this should be bumped in priority. It makes our daily standups very messy when most subtasks are not displayed under the proper epic swimlane.

It's also an issue effecting how we can (or cannot) use our Kanban boards. If your board is configured to to use epics as swimlanes, the moment you filter on something (like assignee = Doug), it suddenly doesn't understand how to put subtasks into epic's swimlanes that are not assigned to me. 

This is impossible to work with as other people will inevitably own epics whereas I only own a subtask, and the board forgets what epics my subtasks belong to. I guess in the context of the applied filter it's correct (like assignee = Doug), but that shouldn't be happening. It's beside the point of having epic swimlanes.

Would definitely like to see a fix for this - will have to find some kind of workaround in the meantime, but I'm not sure what.

Would be nice to see a fix for this as it removes base functionality of the kanban w/ swimlanes.

We have this very issue in several projects now and it is very impeding. Is there any new information on when this issue is being addressed? How many votes would it take to get a higher priority?

(Removed comment as I am using Cloud)

I wanted to add a +1 to this issue, and add some context for why my team think this bug has a critical impact and why we think it should be prioritized higher.
First, I wouldn't be surprised if the requests for this fix are low, because it's a difficult bug to discover – the bug itself is not visible, but instead, tickets can effectively disappear, without any hint as to why they've disappeared. This can cause critical problems for teams when the tickets effectively jump around depending on status. If teams are relying on swimlanes to prioritize and organize work, subtasks simply disappear from the apparent view – in our case, when we use quick filters to see individual's assignments, and when we assign a story to one person and the subtasks to another, this makes those critical subtasks disappear from our prioritized epic when an individual looks at their own work.

We'd like to see this fixed in a much shorter time period due to its impact on our team.

We run into this with high frequency. Applying any quick filter on a Kanban board with Epic-based swimlanes has greatly reduced utility, since the task will be filtered out (i.e. it is assigned to a manager), but the subtasks are not (i.e. assigned to a developer, filtered for with "Just my issues")

Ticket has existed 4 years, status is still "Gathering Impact"  and Low priority, I don't know why anyone bothers communicating with Atlassian, they are too busy changing stuff that worked fine.

Same problem for me.

Same problem for us. In combination with Quick Filters on the board, if that quick filter does not include parent ticket, all subtasks are shown as issues without Epic, which is annoying. 

+1 - this is super annoying.

this is a constant sore spot with our team, especially since we use the board in production reviews with Epic swimlanes so we can say "hey, what are all the things going on with this epic in this sprint?"...but for each one you have to also scroll down to find any orphaned sub-tasks in the "issues without epics" section. It's really easy for things to get lost this way, and is just illogical that subtasks don't sit with their parents.

I also find this incredibly frustrating and surprising.

Same here!

This is highly required for the Epic Swimlane to be usable. I do not see this as a "Low" priority issue.

We are also having exactly the same issue, version 7.3.8.