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 · Accepted solution]

 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.

[Jam Evoc]

Nice!

[Niklas Malmberg]

@Ali Umut Terzi Thank you for the thorough explanation ! 

The logical conclusion is that I have to live with this, or apply one of the suggested workarounds. C'est la vie.

All the best // Niklas

[David Nickell]

A theory .....

does the subtask meet all the filter criteria?  Do you have a subtask status of "Code Review"? is the Assignee empty?   

I think the subtask has to make it through the filter on its own..  When you group by other attributes, I guess the subtask gets included as an "addendum" to the issue.

If you group by subtasks, I assume the starting point are subtasks that are valid in the filter.

Hope this helps

[Niklas Malmberg]

@David Nickell  In my example, I had two possible cases: 
a) A Task has subtasks (then it will appear as a swimlane)
b) A Task does not have any Subtasks (then it will appear under Everything else)

In case a), it's normally a Subtask that is in Code review, but it could also be the parent Task.
In case b), it's the Task itself that is in Code review.

I was looking for a filter to show any of these if they are in Code review without anyone assigned to it. However, as Ali explained, the a) case means (at least in Team-managed Jira projects) that the Task does not have a visible card, it has turned into a Swimline header, and as such, their visibility are completely Subtask-derived. And in my example, all Subtasks are in other states. 

I guess I will implement an automation to cover this case, creating a Subtask just to make the Task visible. Or use another grouping for the board.
Have not gotten around to do that yet though