@elkuku can you plz review/test this PR?

Works as advised and the code looks decent

I think the names of the filters are very project specific (needs one test). Could we rename that to what the query actually checks (which is "has one test" and "has more then one test")?

We could also add a "needs tests" option filtering for issues with 0 tests.?

And then we have this option for "unsuccessful tests". Not sure if that option makes any sense at all or if we should take this into account here?

I think the names of the filters are very project specific (needs one test). Could we rename that to what the query actually checks (which is "has one test" and "has more then one test")?

Actually I do not mind, but these are too long for dropdowns and in some languages it will be more longer.

And then we have this option for "unsuccessful tests". Not sure if that option makes any sense at all or if we should take this into account here?

I was thinking about it, but can not find any situation when we need it :)

@roland-d what do you think?

We could also add a "needs tests" option filtering for issues with 0 tests.?

By default all issues needs tests ;)

P.S.
@elkuku - thinking out loud, does make sense to implement params for the project? Not all projects are the same and params will allow to control project specific things.

I was thinking about it, but can not find any situation when we need it :)

Agree, no need for the unsuccessful tests. At least I have never needed it, these are simply open issues usually asking for more info.

no need for the unsuccessful tests

So let's remove this option then (after this PR is merged of course)

By default all issues needs tests ;)

Well I guess you would need some code to test, so in terms of GitHub you can only test pull requests but not issues, and we are displaying them both in the same list
I mean the filter could display all PRs that have not been tested yet.

does make sense to implement params for the project?

I think we have our #__projects table that holds project specific settings - with the issue at hand - what kind of params are you thinking about?

I mean the filter could display all PRs that have not been tested yet.

Ah, ok. But I am not sure how to achieve this in terms of query

what kind of params are you thinking about?

For example to enable/disable some project specific things like "tests", "easy" and so on.

I am not sure how to achieve this in terms of query

We have the property issue->hasCode and count = 0 ?
Something like...

// No tests yet
case 3:
    $query
        ->leftJoin(
            $db->quoteName('#__issues_tests', 'it')
            . 'ON a.id = it.item_id'
        )
        ->where($db->quoteName('a.has_code') . ' = 1')
        ->group('a.issue_number')
        ->having('COUNT(it.item_id) = 0');
    break;

For example to enable/disable some project specific things like "tests", "easy" and so on.

Yes that would be awesome - I would call this "custom fields" - we actually had that at some point ;)

Hmm, missed has_code field

Seems that it make sense to add 'a.has_code' to case: 1 and case: 2 too because we test only PRs. What do you think?

Seems that it make sense to add 'a.has_code' to case: 1 and case: 2 too because we test only PRs. What do you think?

I think we should check this before displaying the option of testing in the first place, so no need for adjusting the filters here ;)

EDIT: See ⇒ 354807d

Noted and PR is updated :)

OK, let's merge this.

NOTE: wording does meet only JBS requirements!