Project

General

Profile

Actions

Feature #41214

open

Allow the 'OR' Logical Operator in Query

Added by Takenori TAKAKI 3 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

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

Related to Redmine - Feature #4939: List of tasks filtered as OR and not ANDNew2010-02-26

Actions
Actions #1

Updated by Go MAEDA 3 months ago

  • Related to Feature #4939: List of tasks filtered as OR and not AND added
Actions #2

Updated by Emanuel Reisinger 3 months 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)
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.

Actions #3

Updated by Takenori TAKAKI 3 months 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.

Actions #4

Updated by Rita Bylsma 2 months 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)

Actions

Also available in: Atom PDF