GNOME Bugzilla – Bug 209941
imap append loses user flags and tags if server doesn't support UIDPLUS
Last modified: 2005-08-08 06:09:46 UTC
Messages get moved to the appropriate folder (THANKS!!), but the color does not stay changed. Example: NOT from honeywell.com - turn color red CONTAINS evolution in subject - move to Evolution folder So, the above *should* mean that all message from the evo list get moved to the Evolution folder, AND are colored red. But they are not red. If I manually filter the evo folder, all messages that do not contain honeywell will be turned red.
I turned on logging and got this: Applied filter "Not from honeywell" to message from Eric Lambart <lambart@got.net> - "Re: [Evolution] Folders not always working with filters" at Fri, 14 Sep 2001 13:36:25 Action: Set colour to rgb:bc1e/11d5/27ac Applied filter "Subject is evolution" to message from Eric Lambart <lambart@got.net> - "Re: [Evolution] Folders not always working with filters" at Fri, 14 Sep 2001 13:36:25 Action: Move to folder imap://e008328@mail.phxlab.honeywell.com/Evolution imap://e008328@mail.phxlab.honeywell.com/Evolution
Hrm. it would also help if you attach the relevant XML from filters.xml, probably.
Created attachment 40299 [details] My filters.xml
imap can't store color tags. anyways, there's a wishlist to kludge around imap limitations for this but I'm too lazy to find it.
IMAP folders will store tags in the on-disk summary fine.
yes. I know. I closed this because it's a duplicate, not because we won't fix it or whatever.
oops. misread, sorry.
Still seeing this problem with 10032006.
Danw: Imap doesn't store the tags. The only thing saved from the 'info' passed to ::append() are the system flags. Me and Jeff checked this pretty closesly a few days ago. I didn't fix it because its painful - you dont know the uid/etc until you get a 'new messages' notification, and you then need to cross reference that with the append, and queue up the info somewhere too. Yucko. Camel-Imap would (probably) need to add the message to the summary immediately (as does mbox btw), then reconcile that entry with new message notifications which came later on. Doesn't that sound fun?
changing summary to better suit the truth. its not really a filtering thing as such, just imap. Only easy way i can think of doing this is to add a special header to the message when we write it, so that when we summarise it, we can extract those flags again (and any additional extension flags we use). And we hide that header for all other operations we do.
*** bug 204304 has been marked as a duplicate of this bug. ***
Not sure if this helps, but it is added info... filter: not from honeywell turn color red from Evo list move to Evolution folder I just noticed that an Evo message came in, and got moved to the Evolution folder, but was NOT red. At the same time the same message appeared in the trash folder and WAS red.
Now, I just deleted the non-red colored message from the Evolution folder, and it appeared in the trash folder along with the red one. Now there are TWO messages in the Trash folder, one colored black, and one red...
They are probably from different folders.
They are from different folders. One was from the INBOX. It was *supposed* to be filtered into the Evolution folder, instead it was put into the trash, and another was put into the Evolution folder. Why didnt this first one just go to the Evolution folder?? The second one was the one that I deleted from the Evolution folder.
Hmm, elts see. When you filter something, it gets moved, then deleted. Simple eh?
Just wanted to get a status on this. Will it be fixed anytime soon?
I dont think its high on the list right now.
probably won't have time to fix this until sometime after a new imap provider is written to replace the current one and that won't happen until at the earliest 1.4, but probably not till 2.0. anyways, marking as future since this ain't gonna happen anytime soon.
*** bug 230535 has been marked as a duplicate of this bug. ***
the same fundamental problem is an issue with any imap client implmentation, even new code wont help that. If the server doesn't support uidplus, we're pretty well screwed, since we store extra data not stored on the server, by the uid. i think we can only add that extra header idea.
*** bug 258810 has been marked as a duplicate of this bug. ***
also related is bug#242032, tho implementing that won't necessarily help this situation.
label problem could be fixed by the suggestion on 242032, so marking duplicate of that. any other local stuff we can't put in tags, then it cannot be done - it is a limitation of imap. *** This bug has been marked as a duplicate of 242032 ***