GNOME Bugzilla – Bug 527567
Evolution filters applied to non-new mail
Last modified: 2009-10-27 04:46:58 UTC
Please describe the problem: Evolution is applying filters to old mail when it starts up. Version 2.12.3 behaved correctly, but 2.22.1 does not. It seems that the definition of "new mail" is no longer whether the IMAP server considers it new, but whether it's been seen by this instance of Evolution. This is a problem when using evolution on multiple machines (e.g., on a desktop and a laptop), even if they are used at different times. Steps to reproduce: 1) Set up Evolution on the same IMAP account on two different machines ("A" and "B"). 2) Set up a filter on "B" that moves a message to a different folder if it matches a given sender (yourself) and has "read" status. 3) Quit Evolution on "B." 4) On "A," send yourself a message. 5) On "A," read the message. 6) Quit Evolution on "A." 7) Start Evolution on "B." 8) The message should be treated as old, but this is the first time Evolution has seen it on B, so it will execute the filter and move the message. Actual results: The filter is automatically executed. Expected results: The filter should skip the message because the IMAP server considers the message not to be new. Does this happen every time? Yes. Other information: Why this matters: I use filters to file away read messages when I'm done with them. The filters only apply to read and unimportant messages. So instead of deleting messages, I hit CTRL-Y to apply filters to them, which files them away. (I keep most mail in archive folders, and use search folders only on my inbox for mail that I'm not done with.) I realize that this is a non-standard use for filters, but it should work, and it has worked for several years.
I've verified that this was a change in evolution-data-server-2.21.91. Looking at the changes, the patch for bug 510779 looks suspicious.
I did a binary search, and found that it was commit 8469 that caused this. This is from bug 324804. From the discussion there, the problem of breaking archiving filters was discussed, but not resolved.
Preston, Don't downgrade. export FILTER_RECENT=1 and restart of Evo from the same terminal, must restore back the old policy. Yes I posted the archiving policy, and we sort of must remember the last filtered uid, just to make sure that we don't refilter it. but anyways, this fails, if uids are expired.
Something a bit similar is in bug #534938, only my is about drag&drop, for you the message is new in the folder, not caused by user action, but by updating summary on startup. In bug #324804 we added ability to filter on all messages new in summary, not only on those with a \Recent flag. You can either do the above mentioned EXPORT or turn off your filters, do not apply them automatically. You said you apply them manually anyway. The only thing I can think of is adding the option whether apply filters for all new messages or to \Recent messages only in the IMAP provider's setup.
I do have some filters that I need to have applied automatically. I also have archiving filters that I apply manually. The ideal solution for me would be to have two sets of filters, or an option on individual filters to flag them as "never automatic." Of course, I still think it's completely wrong to treat messages that are not unread as being new. Thanks for the environment override. I'll add that to my .bashrc so that I'll have it the next time I upgrade. Right now I'm running 2.22.3 patched with a reverse of commit 8469, which is working perfectly for me.
This version is no longer maintained, which means that it will not receive any further security or bug fix updates. The current stable GNOME and Evolution version is 2.26. Can you please check again whether this issue still happens in Evolution 2.24 or 2.26 and update this report by adding a comment and changing the "Version" field? Thanks a lot. Again thank you for reporting this bug and we are sorry it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE in 6 weeks.
Thanks for taking the time to report this bug; however, closing due to lack of response of the reporter, sorry. if you still see this issue with a current release of evolution (2.26.3 or 2.28.x or later), please reopen. thanks in advance.