Tickets :: Comment on [#6825] OR-combination for flags

* Your Email Address
* Spam protection	Enter the letters below: __ . ..__..___. , / `\| \|\| \|[__ \./ \__.\|__\|\|__\[___ \|
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries