Filtering the list

GET /v1/test-cases takes its filter from the query string. Nothing else — no body, no saved filter object — so a filtered list is a URL you can hand to someone, and the dashboard’s own address bar carries exactly the query it sent.

GET /v1/test-cases?suiteId=6f1c…f1&tag=smoke&tag=payments&priorityMin=high&type=automated

The eight parameters

Parameter	Matches	Repeatable
suiteId	the cases of that suite — or, for a folder, the cases of every suite beneath it	yes
tag	a tag of the title, verbatim — Smoke is not smoke	yes
priority	exactly this level	yes
priorityMin	this level and above — high means high and critical	no
type	manual, automated or eval	yes
state	draft, in_review, active, detached or deprecated	yes
assignee	who is to run it — me (whoever asks), none (nobody) or a member’s userId	yes
q	text found in the title or the description, case-insensitively — text, not a pattern	no

Two rules make the combinations:

• Repeating a parameter is “any of”. tag=smoke&tag=payments is a case carrying either tag.
• Different parameters are “all of”. tag=smoke&type=automated is an automated case tagged smoke.

Absent means everything: with no query at all you get every case of the project. The answer is in tree order — suite by suite, cases by their position, unfiled cases last — whatever the filter, so a filtered list reads like the tree with rows taken out, not like a search result.

A folder widens to its descendants

suiteId with a folder’s id does not answer “nothing — a folder holds no cases”. It answers the cases of every suite under it, at any depth, which is what “everything in checkout” means when checkout is a folder of four suites. The dashboard’s suite picker in the filter bar shows the tree for that reason: pick a folder to see a branch, pick a suite to see one leaf.

A value outside the vocabulary is refused, not ignored

A priority, type or state that does not exist answers 400, and the message lists what does:

unknown priority "urgent" — priorities are low, normal, important, high, critical
unknown type "e2e" — types are manual, automated, eval
unknown state "gone" — states are draft, in_review, active, detached, deprecated

Refused rather than ignored on purpose: a mistyped value that silently matched nothing would look like an empty project. A tag, a suiteId or an assignee id nobody has is simply a filter with no matches — the vocabulary of those is yours, not the platform’s.

assignee=me is resolved on the server from whoever sends the request, so a link with it in — or a plan collection saved with it — means “mine” for each person who opens it.

The dashboard’s URL is the query

The filter bar on Test cases writes what you pick into the page’s URL with the same names — /cases?tag=smoke&priorityMin=high — and reads it back on load. The tree narrows to the matches and the nodes that hold them — the ancestors greyed unless the filter names them — with «N of M» in the bar. So:

• a link to a filtered view restores the controls and the selection in another window;
• Back is a filter change;
• a link that carries a value outside the vocabulary shows the API’s refusal verbatim, with a “Reset filter” beside it and the bar still usable.

Three things to know about the bar

/ focuses the search field and Esc clears the whole filter. Below 1024 px the bar becomes a drawer that edits a draft and applies it in one step. And a filtered view that finds nothing is its own screen — “No cases match this filter” with a reset — not the empty-project screen, which offers to create your first case.