GNOME Bugzilla – Bug 550796
Implement free form filter expression
Last modified: 2015-06-08 12:26:08 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.
Well, please elaborate explicit improvements.
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. Example: http://news.cnet.com/2300-1012_3-6075384-3.html
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.
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?
How about opening new dialog for advanced search?
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.
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
No news on this? At least if we could now if this is confirmed as an enhancement or refused?
We don't really care about UNCONFIRMED vs NEW here.
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: not:(....) and:(....) or:(....) 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.
Created commit 05edaf7 in eds master (3.13.9+) [1] Created commit aab2dd6 in evo master (3.13.9+) [2] [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=05edaf7 [2] https://git.gnome.org/browse/evolution/commit/?id=aab2dd6
When not being aware of the URL https://bugzilla.gnome.org/show_bug.cgi?id=550796#c10 , where can an advanced user find out about this? Any URL to the documentation of this?
(In reply to comment #12) > When not being aware of the URL > https://bugzilla.gnome.org/show_bug.cgi?id=550796#c10 , 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.
I've created https://bugzilla.gnome.org/show_bug.cgi?id=741299 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. :)
*** Bug 671540 has been marked as a duplicate of this bug. ***
Bug #750560 contains a little regression from the above changes.