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 350326 - IMAP: Don't filter messages that have just been moved to Inbox
IMAP: Don't filter messages that have just been moved to Inbox
Status: RESOLVED DUPLICATE of bug 215672
Product: evolution
Classification: Applications
Component: Mailer
2.6.x (obsolete)
Other All
: Normal minor
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[filters]
Depends on:
Blocks:
 
 
Reported: 2006-08-07 19:21 UTC by Adam McMaster
Modified: 2009-10-28 05:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Description Adam McMaster 2006-08-07 19:21:58 UTC 
When the user moves unread messages from a folder to the Inbox, those messages should not then be filtered.  Filtering them after they have been moved can result in those messages being moved back to the folder they were orginally in.

E.g., a message is downloaded and automatically placed in the "Mailing Lists" folder.  The user decides he doesn't want it in that folder, and moves it back to the Inbox for safe keeping.  Evolution then sees this unread message in the Inbox and filters it again, moving it back to the "Mailing Lists" folder.

Other information:
This may only happen with IMAP accounts.
Comment 1 Jeffrey Stedfast 2006-08-09 15:18:51 UTC 
this is very difficult to keep track of because we don't know what the new message uid will be once it is moved back to the INBOX and impossibility of it all just escalates if the user moves messages with any other client (webmail included).

this is just another reason why client-side IMAP filtering is just a broken concept and doomed to failure.
Comment 2 Adam McMaster 2006-08-09 16:31:58 UTC 
Just off of the top of my head, would it be possible to (for example) calculate the md5 checksum of the message (headers + body) and use that as a universal ID?  It seems extremely unlikely that the user would have two completely identical messages, and the overhead would be unnoticable for small messages.

Or perhaps evolution could add a header to each message when uploading to an IMAP server containing an internal ID number (or even just a flag to tell it not to filter it again)?
Comment 3 Jeffrey Stedfast 2006-08-09 17:10:04 UTC 
you can't be serious :)

in order to add a header to each of the messages, they'd all have to be fully downloaded and then have the header appended and re-uploaded (in full) again, deleting the original copies.

Users complain plenty already that Evolution's message-list summary-info fetching takes entirely too long (and I'd agree it does), this type of change will totally not fly with the average IMAP user.

Not all IMAP servers allow custom flags and even that won't help if the user uses multiple mail clients (one from home and one from work, for example)
Comment 4 Akhil Laddha 2009-10-28 05:10:45 UTC 
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 215672 ***