OR-combination for flags

testing IMP 4.2 with most of the other current modules. Am I

Tue, 03 Jun 2008 15:39:50 +0000

testing IMP 4.2 with most of the other current modules. Am I correct that searches are built by one of the following two modes? All Queries: AND( AND(CRIT_1, CRIT_2, ...) AND(FLAG_1, FLAG_2, ...) ) Any Queries: AND( OR(CRIT_1, CRIT_2, ...) AND(FLAG_1, FLAG_2, ...) ) My understanding is that it is not possible to do imap searches for OR-combination of flags, correct? (e.g. all new OR unanswered messages). That could be fixed by making "search flags" on par with the "search criteria", i.e. applying the all/any-switch to flags as well. Even better: provide three all/any-switches for search criteria, search flags and their combination: AND/OR( AND/OR(crit_1, crit_2, ...), AND/OR(FLAG_1, FLAG_2, ...) ) That would enormously extend the space of possible searches by still avoiding a complex GUI for the general nesting of logical operators. Furthermore two little glitches in the current GUI: - In "recent searches", the flags are not mentioned. - "Search Flags" for all the imap flags, but "flagged message" for only the important flag. Martin

> My understanding is that it is not possible to do imap sea

Tue, 03 Jun 2008 15:51:23 +0000

> My understanding is that it is not possible to do imap searches for > OR-combination of flags, correct? (e.g. all new OR unanswered > messages). Why not? A "match any" query, with multiple flags, should work fine...

Though it doesn't seem to. Michael, it looks like if the onl

Tue, 03 Jun 2008 15:53:37 +0000

Though it doesn't seem to. Michael, it looks like if the only criteria you choose are flags, the search doesn't match anything, whether it's an AND or an OR search.

Changes have been made in CVS for this ticket: http://cvs

Fri, 06 Jun 2008 05:50:45 +0000

Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/imp/lib/Search.php?r1=1.113&r2=1.114&ty=u http://cvs.horde.org/diff.php/imp/search.php?r1=2.196&r2=2.197&ty=u http://cvs.horde.org/diff.php/imp/templates/search/search.html?r1=1.29&r2=1.30&ty=u

> testing IMP 4.2 with most of the other current modules. Am

Fri, 06 Jun 2008 05:59:59 +0000

> testing IMP 4.2 with most of the other current modules. Am I correct > that searches are built by one of the following two modes? > > All Queries: AND( AND(CRIT_1, CRIT_2, ...) AND(FLAG_1, FLAG_2, ...) ) > Any Queries: AND( OR(CRIT_1, CRIT_2, ...) AND(FLAG_1, FLAG_2, ...) ) yes. > My understanding is that it is not possible to do imap searches for > OR-combination of flags, correct? (e.g. all new OR unanswered > messages). With my recent changes, it should now be possible to do this. > That could be fixed by making "search flags" on par with the "search > criteria", i.e. applying the all/any-switch to flags as well. Even > better: provide three all/any-switches for search criteria, search > flags and their combination: This is what I have done - I have moved the search flags into the search criteria. Please test and check for smoke, etc. > AND/OR( AND/OR(crit_1, crit_2, ...), AND/OR(FLAG_1, FLAG_2, ...) ) > > That would enormously extend the space of possible searches by still > avoiding a complex GUI for the general nesting of logical operators. This was talked about long ago but isn't easily done - 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. 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. > Furthermore two little glitches in the current GUI: > - In "recent searches", the flags are not mentioned. This has been fixed as a result of the new code (since it pretty much uses the same code previously used for the search criteria). > - "Search Flags" for all the imap flags, but "flagged message" > for only the important flag. I don't understand what this is saying. There is no "important" IMAP flag, only a "flagged for followup" flag.

> Though it doesn't seem to. Michael, it looks like if the o

Fri, 06 Jun 2008 06:00:42 +0000

> Though it doesn't seem to. Michael, it looks like if the only > criteria you choose are flags, the search doesn't match anything, > whether it's an AND or an OR search. I can't reproduce this, but it could be because the new code fixes or it could be because I don't understand what you are trying to say here.

Thinking about this a second... this is going to break virtu

Fri, 06 Jun 2008 06:03:10 +0000

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.

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

Fri, 06 Jun 2008 12:20:21 +0000

> 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.

>> Though it doesn't seem to. Michael, it looks like if the

Sat, 07 Jun 2008 03:12:28 +0000

>> Though it doesn't seem to. Michael, it looks like if the only >> criteria you choose are flags, the search doesn't match anything, >> whether it's an AND or an OR search. > > I can't reproduce this, but it could be because the new code fixes or > it could be because I don't understand what you are trying to say > here. The new code fixes it. So it would be great if the changes could be separated into bugfix and whatever is backwards incompatible.

I like the idea of automatically detecting old-style rules,

Sat, 07 Jun 2008 07:35:45 +0000

I like the idea of automatically detecting old-style rules, and converting them on the fly to the new format.

Just read my earlier post again and think I should clarify t

Sat, 07 Jun 2008 12:27:05 +0000

Just read my earlier post again and think I should clarify the relation between the different versions of search: > (and/or) and (and) < and/or < (and/or) and/or (and/or) < ?? The order I gave represents the usefulness (in my eyes!) of the original search, Michael´s patched search, and my proposed search, not their expressiveness. Michael´s patched version describes a set of searches not completely covering the original, so no backward compatibility. However, it has increased usability by exhibiting a better comprehensibility for the users. The proposed version is a superset of both the original and the Michael´s, so backward compatibility is given (once the save format is handled), although it has a slightly more complex GUI. For me, it is a good trade-off between expressiveness and usability. I vote for my version ;o)) But I would be happy with Michael´s version as well, which is a clean approach seen in many mail clients. I just tested current CVS and everything works well. >> Furthermore two little glitches in the current GUI: >> - In "recent searches", the flags are not mentioned. > This has been fixed as a result of the new code [..] Yes, fixed. Talking about enhancements, may I suggest to delete empty search fields from this display (and storage): they are unnecessary clustering the string with, e.g., "To for ´´ in INBOX", and new searches have a lot of empty fields to offer quick access to the different header fields. Martin

Changes have been made in CVS for this ticket: http://cvs.h

Mon, 09 Jun 2008 23:53:41 +0000

Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/imp/lib/Search.php?r1=1.114&r2=1.115&ty=u http://cvs.horde.org/diff.php/imp/search.php?r1=2.197&r2=2.198&ty=u

Changes have been made in CVS for this ticket: http://cvs.h

Mon, 09 Jun 2008 23:59:27 +0000

Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/imp/lib/Search.php?r1=1.37.10.42&r2=1.37.10.43&ty=u http://cvs.horde.org/diff.php/imp/locale/en_US/help.xml?r1=1.53.6.13&r2=1.53.6.14&ty=u http://cvs.horde.org/diff.php/imp/search.php?r1=2.128.2.29&r2=2.128.2.30&ty=u http://cvs.horde.org/diff.php/imp/templates/search/search.html?r1=1.28.2.2&r2=1.28.2.3&ty=u

I've added auto-updating for old VF rules, so the main eleme

Tue, 10 Jun 2008 00:00:21 +0000

I've added auto-updating for old VF rules, so the main element of this ticket has been completed. > Just read my earlier post again and think I should clarify the > relation between the different versions of search: > >> (and/or) and (and) < and/or < (and/or) and/or (and/or) >> < ?? > > The order I gave represents the usefulness (in my eyes!) of the original search, Michael´s patched search, and my proposed search, not their expressiveness. > > Michael´s patched version describes a set of searches not completely covering the original, so no backward compatibility. However, it has increased usability by exhibiting a better comprehensibility for the users. > > The proposed version is a superset of both the original and the Michael´s, so backward compatibility is given (once the save format is handled), although it has a slightly more complex GUI. For me, it is a good trade-off between expressiveness and usability. BC is *not* given with this format. It would require complex retooling of both current virtual folder rules and development of a new, internal format to save the rules. This is much more than a trivial change. It is a worthy goal, just not one that appears appropriate for IMP 4.2. Moving to another ticket.