After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 550796 - Implement free form filter expression
Implement free form filter expression
Product: evolution
Classification: Applications
Component: general
3.12.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
: 671540 (view as bug list)
Depends on:
Reported: 2008-09-04 08:48 UTC by Ruchir Brahmbhatt
Modified: 2015-06-08 12:26 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Description Ruchir Brahmbhatt 2008-09-04 08:48:48 UTC
Basic search on predefined criteria like sender, subject, receiver, etc. is fine but advanced search in evolution is not so good in terms of usability. When we want to do advanced search on multiple criteria, we have to select advanced search, add criterias and values and then it searches, we need to do this every time. I think search should be easily accessible and usable like gmail. Even outlook 2007 has very usable and quickly accessible advanced search on top of email lists. I think we can add gmail advanced search like facility in evolution with fixed criteria which should be easily accessible like open the form on click of a button or link.
Sorry for short report and less details but this is more a suggestion not a bug so I thought this should be enough.
Comment 1 André Klapper 2008-09-04 14:40:23 UTC
Well, please elaborate explicit improvements.
Comment 2 Ruchir Brahmbhatt 2008-09-04 16:25:38 UTC
I suggest having one button besides standard search textbox. When we click on it, it pops up or expands with additional search fields like from, to, subject, folder, has words, doesn't have, has attachment, date range, etc.
Comment 3 André Klapper 2008-09-04 19:33:56 UTC
What exactly is missing from the quick search bar - combining several conditions? Having another button there will make it even harder to run evolution in 1024x768 resolutions.
Comment 4 Ruchir Brahmbhatt 2008-09-05 06:00:45 UTC
Yes combining several conditions is missing. The new button won't take much space as we can keep just "+" as text instead of "Advanced Search". What do you think?
Comment 5 Ruchir Brahmbhatt 2008-09-15 13:11:37 UTC
How about opening new dialog for advanced search?
Comment 6 Emre Erenoglu 2013-06-05 18:27:52 UTC
I'm not sure if my comment is appropriate for this bug.

I'm using 3.8.2

I would like to search for specific messages from specific senders but I do not want to open advanced search dialog as it takes too much time to populate it.

Can't we do expression search like the Thunderbird add-on "GmailUI/Expressionsearch"?  If we had such function, we could search like:

from:name1 subject:aaabbb

To do this, we have to use advanced search today and this is too much time consuming, too many mouse clicks.
Comment 7 Emre Erenoglu 2013-06-05 18:32:08 UTC
Just to be specific, we shall be able to write more complex search like:
from:aaa to:bbb subject:cccc size:xxxx withattachment:yes

To better understand, just search in google for gmailui
Comment 8 Emre Erenoglu 2014-04-15 13:03:44 UTC
No news on this? At least if we could now if this is confirmed as an enhancement or refused?
Comment 9 André Klapper 2014-04-15 15:35:13 UTC
We don't really care about UNCONFIRMED vs NEW here.
Comment 10 Milan Crha 2014-12-09 08:13:38 UTC
I made this for the development version. There is added a new filter option "Free form expression", in all the Advanced Search dialog, Search folders, Message filters and the Search edit itself (under the magnifier icon above the message list in the Mail view). The expression uses syntax similar to the one noted by Emre above. Some tags can contain additional options, which are separated from the tag name by a dash (<tag>[-<options>]:value). The known tags are:

  Tag        | A   | Meaning
  from       | f   | From header should match (*)
  to         | t   | To header should match (*)
  cc         | c   | CC header should match (*)
  recips     | r   | To or CC headers should match (*)
  subject    | s   | Subject header should match (*)
  header     | h   | given header should match (*)
             |     | the syntax is: h:headerName=value while the equal sign
             |     | is used only as a delimiter, not as a match rule
  exists     | e   | whether given header exists
  tag        |     | given user tag is set on a message
  flag       |     | whether certain flag is set; known special values are:
             |     |   Answered - the message is marked as replied
             |     |   Deleted - the message is marked as deleted
             |     |   Draft - the message is marked as draft
             |     |   Flagged - the message is marked as important
             |     |   Seen - the message is marked as seen (not unread)
             |     |   Attachment - the message has an attachment
             |     | Any other value is checked for its nonemptyness.
  label      | l   | whether certain label is set on the message
  size       | sz  | whether message size, in KB, is equal to the given value
             |     |    Two options are recognized, '<' to get messages with
             |     |    smaller size, and '>' to get messages with bigger
             |     |    size than the given. Example: size->:1024 filters
             |     |    messages which are more than 1MB large.
  score      | sc  | compares 'score' tag on the message against given value;
             |     | default compare is equal, but, similar to 'size' a '<'
             |     | and '>' options can be used
  body       | b   | checks message body for an existence of the given word;
             |     | default compare options is for 'contains', but a regular
             |     | expression can be used if the option is one of the
             |     | "regex", "re" or "r".
  sent       |     | message's Sent date should match (**)
  received   | rcv | message's Received date should match (**)
  attachment | a   | message has (if the value is not any of "no", "false",
             |     | "0") an attachment. Similar to "flag:attachment" tag.

(*) Header comparisons can have matching type option. The default is to check for a 'contains'. The available options are:
   Name        | A  | Meaning
   contains    | c  | matches with contains
   has-words   | w  | matches if contains whole word
   matches     | m  | value's exact match
   starts-with | sw | header value starts with the given value
   ends-with   | ew | header value ends with the given value
   soundex     | se | header value sounds similar to given value
   regex       | r  | the given value is a regular expression
   full-regex  | fr | another type of a regular expression

(**) Dates can be written relatively (positive number means 'in the last X days'), while negative goes into the future. For example, to get messages received in the last 10 days use: "recv:10". An exact date can be used as well, the format can be either YYYY-MM-DD (the preferred one), then ISO 8601 format or a date/date-time locale specific format. If the date/time parse fails, then the condition is skipped. The date compares can have extra options too, it's '<', '=' or '>', where the '>' is the default compare option.

As the first step the given Free form expression is divided into words. If the word doesn't have any (known) tag prefix, then the value is treated as a value to be containing in headers To, CC or Subject. In case of a white-space or any other special character is needed, then enclose the word into double quotes. To get a double quote double it inside quoted text; example: "cite ""here""" is parsed as one word 'cite "here"' (apostrophes for clarity only). For example, 'f:Milan Crha' filters messages for the From containing Milan and the To, CC or Subject containing Crha, while 'f:"Milan Crha"' filters messages for a sender 'Milan Crha'.

There are three special tags, which require special notation. They are:


which allows to create specialized expressions. The default (the most outer) conjunction is 'and'. To change it to 'or' enclose whole filter into 'or:(...)'. For example: 'f:Bugzilla t:Milan' filters all messages which contains 'Bugzilla' in 'From' and 'Milan' in 'To', while
'or:(f:Bugzilla t:Milan)' filters messages from Bugzilla or addressed to Milan.
Comment 11 Milan Crha 2014-12-09 08:21:15 UTC
Created commit 05edaf7 in eds master (3.13.9+) [1]
Created commit aab2dd6 in evo master (3.13.9+) [2]

Comment 12 André Klapper 2014-12-09 11:46:39 UTC
When not being aware of the URL , where can an advanced user find out about this? Any URL to the documentation of this?
Comment 13 Milan Crha 2014-12-09 13:52:05 UTC
(In reply to comment #12)
> When not being aware of the URL
> , where can an advanced
> user find out about this? Any URL to the documentation of this?

I hoped you'll just pick comment #10, polish it and include it in the documentation for such advanced users. I didn't open a separate bug for you, because I knew you'll notice it here and do the best to your documentation work-flow.
Comment 14 André Klapper 2014-12-09 15:57:42 UTC
I've created for this.

Milan: Please file tickets for such stuff, in general. Relying on one person's attention does not scale when there's a public bugtracker which allows any contributor to find open documentation tasks to work on. Thanks. :)
Comment 15 Milan Crha 2015-04-29 16:39:01 UTC
*** Bug 671540 has been marked as a duplicate of this bug. ***
Comment 16 Milan Crha 2015-06-08 12:26:08 UTC
Bug #750560 contains a little regression from the above changes.