GNOME Bugzilla – Bug 242032
color labels not read from or stored to imap message store
Last modified: 2005-09-20 21:12:55 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Steps to reproduce the problem: 1. Use Moz 1.3/1.4 to "label" a message as Personal (green) (really any color, but for the sake of this example we are green) 2. login directly to IMAP a fetch 74 flags * 74 FETCH (FLAGS ($Label3 NonJunk)) a OK Completed see it has the "$Label3" or "Personal" or "green" label stored on the server 3. login to Evolution ... no color whatsoever (not read from IMAP server) 4. set the "Work" (orange?) label in evolution... 5. login directly to imap server... a select INBOX * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Label1 $Label2 $Label3 $Label4 $Label5 $Forwarded $MDNSent Junk NonJunk) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $Label1 $Label2 $Label3 $Label4 $Label5 $Forwarded $MDNSent Junk NonJunk \*)] * 75 EXISTS * 0 RECENT * OK [UNSEEN 75] * OK [UIDVALIDITY 1016827544] a OK [READ-WRITE] Completed a fetch 74 flags * 74 FETCH (FLAGS (\Seen)) a OK Completed 0 logout * BYE LOGOUT received 0 OK Completed Beautimus.. it has not only *not* set the "Work" flag.. but it has cleared the flag that Moz set on the message in the process. 6. (FOR ADDED FUN) .. rm -rf ~/evolution (or if you so prefer, just move it aside) 7. re-start evolution, setup imap account, and login... and POOF.. the color is gone again.. it stores the labels in the local cache, but not the server. Actual Results: Evolution does not play nicely with the $Label[1-4] imap flags Expected Results: it should read the flags from imap and thus colorize the messages, also it should respect the ones that are there when it sets the flags *** especially if they come as an unrequested fetch *** and it should also store the flag in IMAP instead of locally How often does this happen? every time Additional Information: I can provide imap traces (via Sun ONE messaging server telemetry feature) if necessary.
Also, as a side note... this bug also affects the Evolution that comes with Red Hat 9, but strangely enough it seems Red Hat is further behind than Sun :) -- evolution-1.2.2-5 Tommy
The use of cutom IMAP server flags to store labels would be extremely handy, especially for those of us using shared mailboxes at home and at work.
hmm, this should be doable, although we use a mechanism which doesn't use flags for these labels. what does mozilla do if you have multiple labels on the message, does it allow that?
*** Bug 209941 has been marked as a duplicate of this bug. ***
*** Bug 234258 has been marked as a duplicate of this bug. ***
Created attachment 50715 [details] [review] stores labels and junk on imap server Unfortunately, this patch can't be applied yet. It appears to work fairly well with some servers, but others fail terribly. Groupwise advertises \*, and lets us store all of the custom flags as we wish - but it doesn't let us store any custom imap flags in an APPEND command. The 1 line changed to do_append could be removed and it would work though, so that may be worth considering. It would mean message moves (inter-server) would lose the flags though, i.e. not fix 209941.
With the above patch labels interoperate fairly well with thunderbird, and the junk setting partially interoperates with thunderbird (thunderbird seems to ignore changes to the flag by other clients). It should transparently 'upgrade' old installations, uploading label's to the server when flags are synced. It probably wont interoperate terrible well between older versions of evolution - they may just wipe out the labels because of the way they store flags to the server.
Created attachment 50764 [details] [review] updated patch with groupwise workaround
did the patch get a review yet?