Filter results affected by board grouping - but why?

Niklas Malmberg

We're running a Team-managed Jira SW project, with a sprint board.
On the board, we have created a column (state in item workflows) called Code Review, it's where we signal that another developer should do a peer review of the code.
 
I have created a custom filter "Show Unassigned CR" so it should be easy to find these tickets that have not yet been assigned.


And this worked just fine. Except when it's a Task or Story that has subtasks... 

First example: two tickets correctly found. Note the grouping = None


 Second example, board is now grouped by Subtask (which is my normal view, I like those swimlanes to keep Tasks and Subtasks together). Then one of the Tasks are no longer found! 


So, with board grouping set to Subtasks, there are two different ways a Task(or Story for that matter) can show up:
a) If a Task has subtasks, it will appear as a swimlane,
b) If a Task does not have any Subtasks, it will appear under Everything else.

And it turns out that only the b)-Task can be found when the filter definition above is applied (if other conditions are met of course). The a)-Task will be (wrongly) hidden by the filter, although all conditions are met.

Now why is this? 

Ali Umut Terzi

 Hi!  

When your board is set to Group by → Sub-tasks, any parent Task or Story stops being an actual card — it becomes a swimlane header.
Jira quick filters only apply to visible cards.
A swimlane will only be shown if at least one of its sub-tasks meets the board filter and the quick filter conditions.

So:

• b) Tasks without sub-tasks → still show as cards → they are filtered normally ✅
• a) Tasks with sub-tasks → become swimlane headers → if none of their sub-tasks match the filter, the whole swimlane disappears ❌ (even if the parent Task itself meets all filter conditions).

🧩 Practical solutions

1️⃣ Run the filter outside the board view

Try it in Issue Navigator or List View, or in the board with Group by = None.
This behavior is by design when using the Group by Sub-tasks option.

2️⃣ Include both parent and sub-task logic

If you have ScriptRunner, use a JQL like this:

(status = "Code Review" AND assignee IS EMPTY) OR issueFunction in parentsOf('status = "Code Review" AND assignee IS EMPTY')

That way, both the parent issues and their sub-tasks are shown.
(Without ScriptRunner, Jira Cloud’s native JQL can’t “look up” parent-child relations directly.)

3️⃣ Automation workaround

If you really want visual consistency:

• Create a rule → when a parent moves to “Code Review” and is unassigned →
  mark one of its sub-tasks with a label or checkbox like needs-review.
• Then base your quick filter on that (labels = needs-review).
  This forces the swimlane to remain visible.

4️⃣ Change swimlane grouping

If possible, switch grouping to Stories, Assignee, or None — those won’t hide the parent when filtering.

⚙️ Why this happens

This is expected behavior in Team-managed projects.
When grouped by Sub-tasks, the parent’s visibility depends entirely on its children.
Quick filters that look at parent fields don’t affect swimlane headers.

✅ Summary:
This isn’t a bug — it’s how Jira visualizes parent/child items when grouped by Sub-tasks.
If you want the filter to include both parent and sub-tasks, you’ll need either a workaround (automation/label) or an app like ScriptRunner.