Redmine

I assume the and/or dropdown list would be additional to the is dropdown list.

That would be a first step and great for simple filter rules.

For more complex rules it will not satisfy and grouped filters are required (see #4939-60). E.g.

• Status
• AND (Author OR Assignee)
• AND (Release version (custom field) OR Target version)

Further it would be helpful when a field could be used multiple times in filter rules and nested groups are also possible. E.g. the above complex rule expanded (see #4939-60):
Then a more complex filter on a single filed is possible.

• Status
• AND (Author OR Assignee)
• AND (Release version (that's a custom field) OR Target version)
• AND ( ( ( Subject contains abc AND Subject contains foo) OR ( Subject contains abc AND Subject contains bar)) AND Subject not contains foo)

Thanks for your efforts.

Emanuel Reisinger, thanks for your feedback on the patch I submitted. I appreciate your perspective.
Just to clarify, the concept I proposed here(#41214) is quite simple:

• Users can now choose either AND or OR at the beginning of the filters.
• The goal is to keep things straightforward and the UI easy to use, so users can set conditions without confusion.
• This means it doesn’t support grouping filters like Status AND (Author OR Assignee).

That said, I agree that grouping filters, as you suggested, would be useful for more complex cases and likely meet the needs of many users.

Maybe their is a way of having a simple interface and still allow for some mix of AND and OR.
I am thinking of the property of being a necessary or a sufficient condition not creating an extra level, while OR/AND does. (https://en.wikipedia.org/wiki/Necessity_and_sufficiency).

As a first idea, suppose the interface would be like:

Only when A is B
  Only when C is not D
Always when E contains F
Always wenn G is H

If this would mean:
(A is B AND C is not D) OR E contains F OR G is H
the `always' would be semantically correct, but `only' would not. But the problem ist just semantics. The meaning would always be well defined.

Suppose the interface would specify either nothing or 'always when':
A is B
C is not D
Always when E contains F
Always wenn G is H

And that would mean the above. Then we could have at least one level of OR/AND mixes fast :-D

(To keep the interface simple, but have more complex boolean logic, one could even allow the user to assign a name to each non-always line, for grouping)