---

#title: Filtering description: Two keys narrow a table: one filters the rows already loaded, the other changes the query sent to GitLab.

#Filtering

▍filter-bar120×32

filter-barThe filter bar open above a merge request table, with a completion list of real label names from the instance and a running count of the rows that match.

#Two keys

A fetch takes seconds, so the two stay separate. Instant search never issues a request.

#The filter bar

GitLab's merge request connections accept 46 typed filter arguments with real enums behind them, so the bar completes exactly and checks a value as you type it.

• Completion comes from your instance. Labels, usernames, project paths and milestones are read from GitLab, not from memory.
• An invalid value cannot be submitted. Type state:opend and the bar refuses it and lists the values that are valid. The typo never reaches GitLab.
• Dates are real timestamps. updated < 3w becomes an RFC 3339 value bound to a typed variable rather than a string glued into a query.

Every filter is sent as a typed GraphQL variable, never as a search string.

#Quick filters

The five most-used filters are on digits, so the common case needs no typing:

Key	Filter	Key	Filter
1	mine	4	stale
2	failed CI	5	conflicts
3	draft

Chips combine with AND, and each one clears on its own. Digits are reserved for chips, and never select a view or a tab.

#Filter history

The bar remembers the last filters you ran, per view. Press f then ↑ to walk back through them, which is faster than retyping a filter you used yesterday and did not pin. History is capped and kept per view, so a pipelines filter never appears while you are editing a merge request one.

#Keeping a filter

Press P and the filter becomes a pinned tab, together with the scope it was applied to. A view is built by browsing, filtering, and pinning rather than by editing a file, so the bar is where every valid key and value is listed.