starred/cypht

Fork 0

mirror of https://github.com/cypht-org/cypht.git synced 2026-04-25 04:56:03 +03:00

[GH-ISSUE #294] Enhancements: Advanced Search #255

New issue

Closed

opened 2026-02-25 21:34:34 +03:00 by kerem · 8 comments

kerem commented

2026-02-25 21:34:34 +03:00

Owner

Originally created by @lesar on GitHub (Oct 23, 2018).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/294

Originally assigned to: @jasonmunro on GitHub.

This tool is amazing.
I like the Unread and History features a lot.

I think on what can be a significant Enhancement and I believe that expand search features allowing search on all email fields can be very useful.

The most important search field are headers. Allowing search on hidden headers we can move mail in special folders like spam and virus (filter on amavis tag) etc.

Not only hidden headers: fields like can be use to find outgoing message to one user.

Combine search on multiple fields is important too.

This is the first step to introduce filter on incoming mail.

Outgoing mail can be scan by antivirus like clamav.

Originally created by @lesar on GitHub (Oct 23, 2018). Original GitHub issue: https://github.com/cypht-org/cypht/issues/294 Originally assigned to: @jasonmunro on GitHub. This tool is amazing. I like the Unread and History features a lot. I think on what can be a significant Enhancement and I believe that expand search features allowing search on all email fields can be very useful. The most important search field are headers. Allowing search on hidden headers we can move mail in special folders like spam and virus (filter on amavis tag) etc. Not only hidden headers: fields like <To> can be use to find outgoing message to one user. Combine search on multiple fields is important too. This is the first step to introduce filter on incoming mail. Outgoing mail can be scan by antivirus like clamav.

kerem

2026-02-25 21:34:34 +03:00

closed this issue
added the
enhancement

imap

core
labels

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@jasonmunro commented on GitHub (Oct 23, 2018):

Thanks for the feedback. I like the idea of a more powerful search -multiple fields, specific date ranges, any E-mail header, even control over what E-mail accounts and which folders in each account are searched. I think it would make sense to build this as an "advanced search" page so we still have the simple option.

@jasonmunro commented on GitHub (Oct 23, 2018): Thanks for the feedback. I like the idea of a more powerful search -multiple fields, specific date ranges, any E-mail header, even control over what E-mail accounts and which folders in each account are searched. I think it would make sense to build this as an "advanced search" page so we still have the simple option.

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 8, 2018):

Once implemented this should also resolve issue #245 (allow searching of folders not assigned to combined views) and issue #240 (allow the search to specify a character set).

@jasonmunro commented on GitHub (Nov 8, 2018): Once implemented this should also resolve issue #245 (allow searching of folders not assigned to combined views) and issue #240 (allow the search to specify a character set).

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 14, 2018):

Here is what I am thinking of for the advanced search function. The "+" in the terms section will allow you add additional terms with an "and/or" setting. The "+" in the time section will do the same but only "or" since "and" does not make sense for date ranges. The source section will allow you to select folders from any configured IMAP account. Eventually I will include other data sources like POP3 and feeds but I'm going to start with IMAP. Lastly the other section will have various other options like character set and message flags, etc.

@jasonmunro commented on GitHub (Nov 14, 2018): ![adv_search](https://user-images.githubusercontent.com/3793556/48518238-90c88480-e82e-11e8-9b6c-24abc04d5392.png) Here is what I am thinking of for the advanced search function. The "+" in the terms section will allow you add additional terms with an "and/or" setting. The "+" in the time section will do the same but only "or" since "and" does not make sense for date ranges. The source section will allow you to select folders from any configured IMAP account. Eventually I will include other data sources like POP3 and feeds but I'm going to start with IMAP. Lastly the other section will have various other options like character set and message flags, etc.

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@dumblob commented on GitHub (Nov 18, 2018):

@jasonmunro I think that's a decent proposal MVP. For a post-MVP version the following could be considered.

"grouping of terms" using e.g. parentheses
"case insensitive" option (per term)
"search in a whole raw email" - i.e. including all email headers
(I'm though not sure which of these options are supported e.g. by IMAP)

Generally I'm fine with anything which supports search of a deliberate substring in all email bodies of an email. E.g. if I'll search for /html> (yes, the first < is missing), it'll find at least all HTML emails. If I'll search for tm, it'll find also at least all HTML emails (tm is in the middle of a word html). If I'll search for conjunction ell AND llo in Hello world! it shall definitely find this email (i.e. overlapping search terms shall be evaluated independent from each other).

I'm writing these examples, because many email providers don't support search of deliberate substrings, but just whole words, or a search just from the beginning of a word or a search in the rendered text (i.e. no search of HTML tags, but just the visible text itself), etc.

@dumblob commented on GitHub (Nov 18, 2018): @jasonmunro I think that's a decent proposal MVP. For a post-MVP version the following could be considered. 1. "grouping of terms" using e.g. parentheses 2. "case insensitive" option (per term) 3. "search in a whole raw email" - i.e. including all email headers (I'm though not sure which of these options are supported e.g. by IMAP) Generally I'm fine with anything which supports search of a deliberate substring in all email bodies of an email. E.g. if I'll search for `/html>` (yes, the first `<` is missing), it'll find at least all HTML emails. If I'll search for `tm`, it'll find also at least all HTML emails (`tm` is in the middle of a word `html`). If I'll search for conjunction `ell` *AND* `llo` in `Hello world!` it shall definitely find this email (i.e. overlapping search terms shall be evaluated independent from each other). I'm writing these examples, because many email providers don't support search of deliberate substrings, but just whole words, or a search just from the beginning of a word or a search in the rendered text (i.e. no search of HTML tags, but just the visible text itself), etc.

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 19, 2018):

@dumblob as always I appreciate your feedback. Some thoughts on your points:

For now I'm only allowing 2 fields for anything that can have an and/or condition (search term and target field) to avoid grouping considerations. Grouping would be nice, but I'm not sure it's needed for MVP.
According to the RFC, IMAP searches are case insensitive and substring matches (the term "RM" should match "farm"), which is what I plan to support for now. I could post process for case sensitive eventually. IMAP supports negative matches easily so I might add that for the and case of "X and not Y".
IMAP supports searching the entire raw message I believe, and our simple search is already capable of this I think.

This is over 50% done, including all of the UIt. Once I have it fully wired up I will run some tests against your examples and see how it goes!

@jasonmunro commented on GitHub (Nov 19, 2018): @dumblob as always I appreciate your feedback. Some thoughts on your points: 1. For now I'm only allowing 2 fields for anything that can have an and/or condition (search term and target field) to avoid grouping considerations. Grouping would be nice, but I'm not sure it's needed for MVP. 2. According to the RFC, IMAP searches are case insensitive and substring matches (the term "RM" should match "farm"), which is what I plan to support for now. I could post process for case sensitive eventually. IMAP supports negative matches easily so I might add that for the and case of "X and not Y". 3. IMAP supports searching the entire raw message I believe, and our simple search is already capable of this I think. This is over 50% done, including all of the UIt. Once I have it fully wired up I will run some tests against your examples and see how it goes!

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 21, 2018):

MVP for advanced searching is in the master branch! :) There is more to be done of course, but it's functional. There are a few things left to work out, specifically the message view from advanced search does not have the correct "parent" list set, and the previous/next links are from the IMAP folder source, not the search results. Also I have not integrated this with the saved searches module set yet. The other thing I want to add is the ability to have labels terms as "negative" matches (A but not B). Here is a look at the search form:

After clicking search the form collapses and the results are below:

@jasonmunro commented on GitHub (Nov 21, 2018): MVP for advanced searching is in the master branch! :) There is more to be done of course, but it's functional. There are a few things left to work out, specifically the message view from advanced search does not have the correct "parent" list set, and the previous/next links are from the IMAP folder source, not the search results. Also I have not integrated this with the saved searches module set yet. The other thing I want to add is the ability to have labels terms as "negative" matches (A but not B). Here is a look at the search form: ![adv_search1](https://user-images.githubusercontent.com/3793556/48821284-380d5600-ed1e-11e8-84a8-201cb8cb0d9a.png) After clicking search the form collapses and the results are below: ![adv_search2](https://user-images.githubusercontent.com/3793556/48821307-49eef900-ed1e-11e8-8c46-9571d1d854aa.png)

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@dumblob commented on GitHub (Nov 21, 2018):

@jasonmunro that looks really good, thanks. Also it seems the whole content of the input box under "Terms" is taken as one substring and is not split into words or anything (like other providers do and I find it really annoying as usually it's impossible to specify a substring containing e.g. empty or any other UTF characters). Which is exactly what I would expect, so thank you again.

@dumblob commented on GitHub (Nov 21, 2018): @jasonmunro that looks really good, thanks. Also it seems the whole content of the input box under "Terms" is taken as one substring and is not split into words or anything (like other providers do and I find it really annoying as usually it's impossible to specify a substring containing e.g. empty or any other UTF characters). Which is exactly what I would expect, so thank you again.

kerem commented

2026-02-25 21:34:34 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 28, 2018):

I have fixed the parent list + previous/next link issues, so I'm going to close this as done for now. I will create new issues for the other enhancements (integration with saved searches and the ability to toggle a "not" prefix for terms).

@jasonmunro commented on GitHub (Nov 28, 2018): I have fixed the parent list + previous/next link issues, so I'm going to close this as done for now. I will create new issues for the other enhancements (integration with saved searches and the ability to toggle a "not" prefix for terms).