These are some notes from a thread on the roundup-users mailing
list. They may serve as inspiration for enhanced search/report
operations.

The question was:

> 2. Can I do logical OR operation on database filtering, concerning
> different properties?
> For example, I want to list issues with "assignedto=15 OR actor=15".
> Do we have a built-in query for this, or shall I utilize
> filter_sql, or any other custom solution?

A POC I wrote years ago implemented this using two queries (called
component queries) and implementing set operations between them. IIRC
this was tricky because of the way the queries were saved/defined at
the time.

The idea was: query1 would return the result set for "assignedto=15"
and query2 would return the result set for "actor=15".

Then you would define the URL (using the issue.setsearch.html
template):

  @set1=query1&@set2=query2&@op=UNION&@columns=...&@sort...&@group=...
  
to submit to a new action: setsearch.

This (in theory) allowed you to do the equivalent of:

  query1 UNION query2  - the is the OR operation requested
  query2 INTERSECT query - show me all issues that have the word issue
                           and the word search
  query1 DIFFERENCE query4 - give me all issues that are open and have
                             the word search but do not include the
                             word wiki.
   
The POC only implemented the UNION operation. The issue.setsearch.html
template was based on issue.search.html. The template removed the
filter column. It added text fields for @set1, @set2 and a select list
for @op.

Since the POC was done before the current query mechanism was defined,
all of the component searches were listed in the left sidebar. With
the current query management interface, these additional queries can
be hidden.

Consider using an RPN style method similar to the query mechanism for
links/multilinks. So:

   @q=query1,query2,UNION,query3,DIFFERENCE

would combine the items from query1 and query2 then from that set
remove the items in query3. This allows multiple operations among
queries.

The POC didn't have a method for saving these queries.  Using the RPN
format could allow storing these queries in the query class along with
the other queries. So they can be displayed in the left hand sidebar
and shown/hidden with the rest of the queries.