Feature #41214
openAllow the 'OR' Logical Operator in Query
0%
Description
Purpose:
Enable users to use the 'OR' logical operator when setting filters in queries for issue lists, Gantt charts, time entries, and more, allowing filters to be connected using 'OR' (e.g., Filter A OR Filter B).
Background:
Redmine’s query function lets users apply various filters, offering powerful search capabilities. However, it currently only supports the 'AND' logical operator between filters (e.g., Filter A AND Filter B). This means that users cannot create queries to search for issues where, for example, either the author or the assignee is a specific user. Adding the option to use the 'OR' logical operator between filters would make Redmine’s queries more flexible and expressive.
Implementation:
As shown in the attached screenshot, I will add a dropdown list to the query form. This list will let users select the logical operator ('AND' or 'OR') between filters. The default will be 'AND' to ensure existing queries remain unaffected.
I have created a patch and will attach it along with the corresponding test code.
Files
Related issues
Updated by Go MAEDA about 1 month ago
- Related to Feature #4939: List of tasks filtered as OR and not AND added
Updated by Emanuel Reisinger about 1 month ago
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)
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.
Updated by Takenori TAKAKI about 1 month ago
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.
Updated by Rita Bylsma 23 days ago
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)