action #93246

Updated by okurz 3 months ago

## Motivation
As a test reviewer and member of one of many QA squads I want to find unreviewed openQA test failures on /tests to have access to a single page showing all failures needing review work.

Also see parent #89062

## Acceptance criteria
* **AC1:** A query parameter "todo=1" parameters on /tests can be specified to show only jobs needing review, same as we do on /tests/overview a label, e.g. "failed/incomplete/timeout_exceeded" with no "label" nor "bugref"

## Suggestions
/tests can already be configured like , even over UI elements. Also /tests already shows a comments icon but makes no distinction like on /tests/overview or "next & previous" between "plain comment", "label" or "bugref".

* Try t/ui/01-list.t and see if you can extend it
* Add query parameter to filter only jobs that need review, e.g. "todo=1", same as on /tests/overview . At best use the same logic to prevent duplication

* Optional: Add UI element to configure this, e.g. again like on /tests/overview the "todo" checkbox
* Optional: Add further filter query parameters (+doc, +UI control elements) for
* job group include/exclude regex (similar to what we have on the index page)
* filter for "no group/any group"
* test module include/exclude regex
* further filter possibilities, e.g. medium, flavor, arch, machine

## Further details

We already provide an IRC bridge that notifies about all unreviewed test failures (see and ).

Out of scope
* Don't care about the "running" or "scheduled" jobs on /tests as long as they at least show something useful when no manual query parameters are used or no filtering box selection has been made.
* Performance improvements on /tests, as the feature should only be activated on explicit request by users
* Don't care about the number of jobs that are displayed after all the filters apply. is one example showing that there can be enough "review candidates" depending on the specified test suite
* Don't care about changing the limit of jobs (e.g. more than 500)
* Don't care about filtering the job for other parameters like job group, scenario name, result, state, etc.