### Summary The implementation of https://gitlab.com/gitlab-org/gitlab/-/work_items/358416+ mismatches some customers expectations. Or, a different change resulted in the problematic front-end behaviour explained below: [Our release note](https://docs.gitlab.com/releases/18/gitlab-18-4-released/#issue-boards-now-show-complete-epic-hierarchies) advise to: > view all issues from child epics when filtering by a parent epic But, child work-items are now shown on `/boards?group_by=epic` pages under _both_ their: - immediate parent epic - and that epic's own parent even when no filter is applied. Compare these 2 views (ping @katrinleinweber-gtlb for Planner invite into that demo group): - https://gitlab.com/groups/katrinleinweber_ultimate_group/-/boards?epic_id=5122369&group_by=epic - https://gitlab.com/groups/katrinleinweber_ultimate_group/-/boards?group_by=epic ### Steps to reproduce / example [katrinleinweber_ultimate_group](https://gitlab.com/groups/katrinleinweber_ultimate_group/-/boards?group_by=epic) 1. Create group epic with a child epic. 2. Add a work item to the child epic. =\> board is still clean. 3. Add another work item to the group epic. =\> Previous work item is shown twice. ### What is the current _bug_ behavior? This duplication can clutter a board, if a top-level epic has many child epics with many work items, but also direct child items. One customer [internally](https://gitlab.zendesk.com/agent/tickets/714025) explain this problem as follows: cc @manuel.kraft @gweaver > 1. Defeats the purpose of sub-epics: > - Sub-epics exist to break down work into manageable, logically grouped units with their own scope and timelines. Automatically flattening this hierarchy in boards removes that separation and makes sub-epics redundant. > 2. Breaks roadmap clarity and planning: > - Roadmaps depend on clearly defined start/end dates at the appropriate level (epic vs sub-epic). If all child issues are surfaced at the parent level indiscriminately, it becomes impossible to accurately represent timelines or ownership. > 3. Introduces noise and confusion in boards: > - Teams using boards for Iteration Planning now see an inflated and misleading set of issues. This makes it harder to track progress and undermines the usefulness of boards as an operational tool. > 4. Inconsistent behaviour across views: > - This change creates a disconnect between Issue Boards and other parts of GitLab (e.g., issue lists, roadmap views), leading to confusion and lack of trust in the system. > 5. Removes intentional structure > - Teams design their epic/sub-epic hierarchy deliberately. This update overrides that structure instead of respecting it. ### What is the expected _correct_ behavior? Issues should only appear under their **direct parent epic** in Epic swimlane views. The full hierarchy behavior (showing child epic issues under a parent epic) should only be activated when a user has **explicitly filtered by that parent epic**, which is what the original MR (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/198718) and the release note described. ### Agreed solution > **Decision reached in **[**this thread**](https://gitlab.com/gitlab-org/gitlab/-/work_items/598681#note_3316495284)** — May 2026** Participants: @mmacfarlane, @gweaver, @nickbrandt, @samdbeckham, @mksionek * Set `includeSubepics: false` in the GraphQL request when Epic swimlanes are active and the user has not explicitly filtered by a specific epic. This preserves the intended behavior from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/198718 (showing full hierarchy when filtering by a parent epic) while preventing board clutter on unfiltered or general views. * Scope consideration from @nickbrandt: `includeSubepics: false` should apply anytime Epic swimlanes are turned on, not only when there are no filters. The same duplication problem can occur if a user filters by a top-level epic while viewing in swimlanes. The `includeSubepics: true` behavior should only activate when a user explicitly filters by a specific parent epic _without_ Epic swimlanes enabled, or in contexts where the full hierarchy is intentionally desired. For Future consideration: A display option toggle (e.g., under Epic Swimlanes settings) should be considered to let users opt in to seeing all nested child items/issues. This would support use cases like boards filtered to a custom Feature work item type where seeing all children across sub-epics is desirable. **What is NOT in scope:** - ~~Revert of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/198718~~ — the underlying feature is valuable and should be preserved. - ~~A full toggle~~ — the fix should be behavioral (automatic), not require user configuration for the default case. ### Relevant logs and/or screenshots {width="761" height="600"} There is no filter. This view would be expected for [/boards?epic_id=5122369&group_by=epic](https://gitlab.com/groups/katrinleinweber_ultimate_group/-/boards?epic_id=5122369&group_by=epic), though.