Filters & saved views
The Issues list narrows down to any condition you can describe — from "my open issues" to "everything that reached Done last week and is no longer there". The condition is assembled with the mouse, without a query language, and what you assemble can be saved and reused: on a board, in a dashboard widget, in an automation rule, in search and through the API.
Quick filter
Above the issue list there is a row of chips and an "+ Filter" button. The button opens a small popup with three controls — field, operator, value — and the condition you add becomes a chip; the × on the chip removes it.
Chips combine with AND: an issue shows up when all of them match. Nine of the most common fields are available as quick filters: status, summary, priority, type, assignee, labels, due date, created and updated. The rest live in the builder.
Condition builder
The "Conditions" button expands the builder. Here conditions form a tree rather than a list:
- an AND group — every condition inside must match;
- an OR group — at least one must match;
- the NOT checkbox on any condition or group inverts it;
- groups nest — "+ condition" and "+ group".
This expresses what other trackers need a query language for: "high priority and either unassigned or already past its due date".
The quick filter and the builder apply together, combined with AND. An empty group narrows nothing, and the builder says so.
Fields
| Field | What it matches |
|---|---|
| Key | The issue key, whole or in part. |
| Summary, Description | The title text and the description text separately. |
| Any text | One condition across both at once. |
| Status | The current status. The only field with history. |
| Status category | The broad workflow buckets: To do, In progress, Done. Independent of how statuses are named in your scheme. |
| Priority, Issue type, Resolution | Values of the matching catalogues. |
| Story points | A number: equal, greater, less, empty. |
| Created, Updated, Due date | Dates — with functions such as "start of week". |
| Project | Needed when the view spans several projects. |
| Assignee, Reporter, Co-assignee, Watcher | People; the value comes from a picker or from the "me" function. |
| Labels | An exact label, a substring, or whether there are labels at all. |
| Sprint | A specific sprint or, via a function, every open one. |
| Parent, Linked issue | Hierarchy and links: subtasks of one parent, everything linked to an issue. |
The list of fields comes from the server, so it is the same in the quick filter and in the builder, and only the operators that suit the chosen field are offered. The same set is available to assistants and the API.
Operators
| Group | Operators |
|---|---|
| Comparison | =, ≠, is one of, is none of |
| Ordering | <, ≤, >, ≥ — for numbers and dates |
| Text | contains, does not contain, starts with |
| Emptiness | is empty, is not empty |
| History | was, was not, was one of, changed, changed to, changed from |
Empty values
The ≠ operator does not match an empty field: "assignee ≠ Ivanov" returns issues assigned to someone else, but not issues with no assignee at all. This is the behaviour trackers converge on, and it keeps half of your result from being "nobody's".
To get exactly the blank ones there are is empty and is not empty; to get both, put the two conditions into an OR group.
Context functions
A value has a second mode — "Use a context function". The function is evaluated when the filter runs, so a saved view stays correct tomorrow and for a different person.
| Function | What it substitutes |
|---|---|
currentUser() | Whoever is looking. "My issues" is assignee = currentUser(). |
membersOf(group) | Every member of the given user group. |
openSprints(), closedSprints(), futureSprints() | Active, completed and planned sprints. |
now() | The current moment. |
startOfDay(), endOfDay() | The bounds of the day. |
startOfWeek(), endOfWeek() | The bounds of the week (weeks start on Monday). |
startOfMonth(), endOfMonth(), startOfYear(), endOfYear() | The same for a month and a year. |
Date functions take an offset — the field next to the name: -1d, -2w, +3h. Units are s (seconds), m (minutes), h (hours), d (days), w (weeks). "Overdue as of this morning" is Due date < startOfDay(), and "updated in the last week" is Updated > now() with the offset -1w.
Day and week bounds are computed in UTC
If your team works far from the zero meridian, startOfDay() may differ from your midnight by several hours. For "in the last 24 hours" the safer choice is now() with the -1d offset.
Status history
The was / was not / was one of / changed / changed to / changed from operators read the transition log and apply only to the Status field:
- was Done — the issue reached that status at some point, even if it is back in progress now;
- changed to In progress — a transition into that status ever happened;
- changed from Done — the issue was pulled back out of it.
No history is kept for the other fields, so "who was this assigned to last month" cannot be asked — not here and not in the reports.
Sorting and the counter
Clicking a column header sorts the list: ascending → descending → unsorted. The whole result is sorted on the server, not just the page you see. On a phone, where there are no headers, the field and the direction are picked with a selector above the list.
Next to the saved filters the page shows "Found: N" — how many issues match the condition in total, regardless of how many are loaded on screen.
Saved filters
A condition you assembled can be saved under a name; it then appears in the selector above the list, in one of two groups:
| Group | Who sees it |
|---|---|
| Mine | You (and an administrator). |
| Shared | Everyone on the instance — the "Shared (visible to everyone)" checkbox when saving. |
The buttons next to it: "Save filter" — a name and the sharing checkbox — and "Delete" for the selected one (your own; an administrator may delete any).
Picking a filter replaces the current conditions: the quick filter is cleared, the whole tree goes into the builder, and the sort saved with the filter is applied. The condition stays visible and editable — a filter is not a black box.
A filter is saved together with the active project: the selector shows the filters of the current project plus those saved without one. Save a filter with no project selected if it should be available everywhere.
A shared filter does not share access
Permissions are checked when the filter runs, and against whoever is looking. The same shared filter shows you and a colleague different lists if your project access differs. Share the slices that are useful to everyone — "overdue in the department", "in progress for more than two weeks" — not as a way to hand out access.
Service Desk customers do not use filters: they get the portal with the list of their own requests.
Where else a saved filter works
A filter is a product-wide object, not a setting of one page:
| Where | What it does |
|---|---|
| Board | The board shows the filter's result instead of every issue in the project — see Boards → Board from a filter. Only a shared filter can be picked: the whole team sees the board. |
| Dashboard | The "Filter result" widget — a list of issues or a single number, see Reports & analytics → Dashboard. |
| Automation | A scheduled rule walks the result and runs its actions for every issue — see Automation → Schedule over a selection. |
| Search | Saved searches are the same filters, see Search → Saved searches. |
| AI & API | An assistant builds the very same condition tree — see AI & API access. |
Avoid deleting a filter a board or a rule points at: the board falls back to "all issues in the project" and says so, and the rule logs that its selection is unavailable.
Limits
- At most 64 conditions per filter and 8 levels of nested groups. The add buttons go dim once the limit is reached.
- There is no text query language — conditions are assembled in the builder. To share one, save it as a filter.
- The result cannot be exported to a file.
- Custom fields are not in the builder yet: they are matched by automation rules, and on the issue page they have their own tab.
- A filter can only narrow the result. No condition reveals issues from projects you cannot access.
Next steps
- Issues & tasks — the issues themselves, their fields and links.
- Boards & sprints — a board driven by a filter.
- Reports & analytics — ready-made slices you do not need a filter for.
See also
- Search & notifications — full-text search and how it differs from a filter.
- Automation — rules that walk a selection on their own.
- AI & API access — the same condition tree for assistants and scripts.