[Tickets #6825] Re: OR-combination for flags

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/6825
-----------------------------------------------------------------------
 Ticket             | 6825
 Updated By         | xk3 at mompl.org
 Summary            | OR-combination for flags
 Queue              | IMP
 Version            | 4.2
 Type               | Enhancement
 State              | Feedback
 Priority           | 1. Low
 Milestone          |
 Patch              |
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


xk3 at mompl.org (2008-06-06 08:20) wrote:

> This was talked about long ago but isn't easily done

uh, haven't found that discussion ...

> how do you "lump" queries together?  For example, how do I
> specify that I want (A AND B) OR (C AND D) - the result must
> contain A/B pairs or C/D pairs - not (A AND B OR C) AND D –
> the result must contain D and must contain either A/B pair or C.

Yes, indeed.

> In other words, nobody has come up with an elegant way
> of making the UI handle 'parentheses' so, thus, the reason
> we have either all AND or all OR searches.

I do not propose to allow arbitrary nesting/parentheses, as the GUI would
become very complex (drag and drop for some indention pops into my mind).
You pointed this out as well. However, if you have two fixed and,
therefore, only three logical operators, the GUI should not be too
complicated:

Search Criteria (O OR  X AND)
    Criteria 1
    Criteria 2
    Criteria 3

X  Match Criteria AND Flags
O  Match Criteria OR  Flags

Search Flags (O OR  X AND)
    Flag 1
    Flag 2
    Flag 3

(with O unselected and X default option)

This GUI keeps up the differentiation between Criteria and Flags, which,
in general, is fine for me. It does not allow every logic combination of
sub-searches, but a lot more than before: the set of new searches would be
a real superset of the current searches and the searches possible with your
or-patches.

I do not know about elegance, and I do not know whether everybody finds
this GUI as intuitive as I do. Furthermore, I cannot say that this proposed
GUI is the non-plus-ultra (free nesting would be), but IMHO(!) it is much
superior to the current and to your patched version. Ordering them would
give for me:

    (and/or) and (and)   <    and/or    <   (and/or) and/or (and/or)    <
  ??

> Thinking about this a second... this is going to break
> virtual folders with flags, so it is doubtful that this
> is something that can go into IMP 4.2.

For already saved searches in "old" format (making trouble for your
patches as you mentioned), using the X-selection as default for 2nd and 3rd
operator would keep up the old behavior. Just saving the searches in new
format if changed, or writing a little upgrade script for the DB should be
easy.

I do wait with smoke-testing your already provided patches until I get
feedback to this proposal. If you reject it, I'll go with your patches, as
saved searches are not a problem for my users.


ad "flagged for followup": ack, forget what I said.