-
Bug
-
Resolution: Unresolved
-
Medium (View bug fix roadmap)
-
None
-
6.3.4, 7.1.0, 7.0.5, 7.11.0, 7.10.2, 8.16.1, 9.4.15, 9.12.17
-
Standalone
-
6.03
-
17
-
Severity 3 - Minor
-
7
-
Summary
When Swimlanes are based on Epics and there are Issues linked to Epics which are not available in the board, then these Issues are still visible in Backlog (for Scrum) & Kanban Backlog (Kanban) but invisible in Active Sprints (both Scrum and Kanban)
Steps to reproduce
- Create board A (Scrum) for project A, which should filter all issues in project A
- Create project B, then create Epic B in project B
- Create Issue A in project A, then link it to Epic B
- Create a sprint in board A, add Issue A to it and start it
- Configure board A and base Swimlanes on Epics
Steps to reproduce (scenario 2)
- Create a new Kanban project using the sample issues template.
- Remove Kanban board sub-filter via board > configure > general.
- Configure "Hide completed issues older than" to show all option.
- Create a filter like this -> project = ABC and updated >= -100d order by RANK asc
- Configure board base Swimlanes on Epics
- Create a new Epic in the kanban backlog.
- Create a new stories via CSV import by changing the date creation and date updated to order than 100 days.
- Make sure you have the stories linked to the Epic Link and set the issue status to the "In Progress" category status.
- For example, the CSV format (note the date is older than 100 days):
Summary, Assignee, Reporter, Issue Type, Epic Name, Description, Priority, Created, Updated, Epic Link, Status "Test issue 1", admin, admin, Story, Story test 1,,,10/01/2023,06/03/2023, KAN-18, "In Progress"
- In the work mode (clicking Kanban board at the side bar), the new Epic is missing in the board.
Expected behavior
Issue A is visible in Active Sprints of board A
Actual behavior
Issue A is invisible in Active Sprints of board A
If Issue Count is enabled for the Columns, we can see a mismatch in the number of issues like this:
In Backlog mode, all the 4 issues are visible:
Notes
The same behavior applies to both Scrum and Kanban boards
Original Description
We have put some stories in our sprint that are connected to epics from an "Epics" project, which contains Epics that span multiple projects.
The Saved Filter for the board is the default:
project = "This Project" ORDER BY Rank ASC
In "plan" mode I can see the tasks
In "work" mode when we select "swimlanes by epic" these stories disappear. They also do not show under "issues without epics".
The workaround suggested elsewhere is to change the Saved Filter to:
project = "This Project" OR ( project = Epics AND type = epic ) ORDER BY Rank ASC
However, this then means that when you go to "plan" mode and show the Epics panel, you then see all multi-project Epics, even if they do not have any tasks in the current project.
- is related to
-
JSWSERVER-13173 It might be confusing that how many issues there are actually on a Kanban board with Epic swimlane
- Closed
- relates to
-
-
- Closed
-
- was cloned as
-
-
- Closed
-
[JSWSERVER-11318] Stories from external epics disappear in swimlanes
This is a bug and I don't want to use workaround. This should get fixed. Jira in bigger companies needs to be able to handle this.
Thank you Mathias, that magic query worked!
Our sprint permissions are the same across all projects in the query. I went with the 2nd one you suggested to be safe.
project in (PROJECT1, PROJECT2, PROJECT3, PROJECT4) AND (component = "Team Name" OR issueFunction in epicsOf('component = "Team Name"')) ORDER BY Rank ASC')
Hi Shakthi Oke,
to also get the epics into the Board the filter could be changed to:
project in (PROJECT1, PROJECT2, PROJECT3, PROJECT4) AND component = "Team Name" OR issueFunction in epicsOf('project in (PROJECT1, PROJECT2, PROJECT3, PROJECT4) AND component = "Team Name"') ORDER BY Rank ASC
BUT be aware, that the issueFunction affects the Projects in the boards, so that, if you work in a Scrum Board, some issues might appear when Starting or Completing sprints, as those functionalities depend on the sprint permissions in all projects covered by the board. It can help to enclose the while query above and reduce the projects again. Like:
project in (PROJECT1, PROJECT2, PROJECT3, PROJECT4) AND (component = "Team Name" OR issueFunction in epicsOf('component = "Team Name"')) ORDER BY Rank ASC')
The first query will give you all Epics from all projects back. The second one shows only Epics from the mentioned projects - but will also have less effect on Sprint permissions).
We have Script Runner, would anyone know what the query would be if our default board query is this
project in (PROJECT1, PROJECT2, PROJECT3, PROJECT4) AND component = "Team Name" ORDER BY Rank ASC
We can have tickets across multiple projects but use Components to identify a team.
This should also be issue linked to this: https://jira.atlassian.com/browse/JSWCLOUD-21601
I have another potential workaround for this, but would still like it resolved properly.
Our organization has a central project containing all epics used by leadership to define high-level efforts. Once the epic is created, individual teams, (each using separate projects), will populate those epics with stories. There are no "epic" issuetypes in those team-projects, and no "story" issuetypes in the leadership project.
If I write my filter for my by-epics board something like this:
project = myteam OR ( project = leadership AND issuetype = epic ) ...
...the board shows up under the leadership project and the myteam project, which is undesireable.
However, if I assign project categories to these projects, this problem is avoided. Assuming I create two new categories, one called "leadership" and the other "teams" and assign "leadership" to the leadership project and "teams" to each team-specific project (i.e. myteam in the example above), I can then avoid this problem with this filter:
project = myteam OR ( category = leadership AND issuetype = epic ) ...
This filter still pulls in the epics from the leadership project, but doesn't cause the board to be displayed under the leadership project's list of board. It only shows up under the myteam project's board listing.
This approach works great if you aren't already using categories, or if you are using them, but your board containing the epics doesn't share that same project category tag with other projects in your Jira instance. If it does, and they contain epics, it will pull those in too, which may or may not be desirable, depending on your situation.
Issue is still present in Jira v9.12.8