Branch and trunk A message which has it's priority changed via filter action will not retain the changed priority if the message is moved manually or via filter action (either using two separate filters or (trunk) multiple actions in one filter) the priority in destination folder will reflect the original priority value. This applies to incoming messages regardless of what the original priority setting was. Tested on IMAP account, move to another folder on same account. Steps: 1. On IMAP account, set a filter to match subject text and set filter action to change priority to Highest. 2. Send yourself a message with priority of Low, get the message. Message is caught by filter, priority column shows the priority set to Highest. 3. Drag the message to another folder on the same account. View the message in its destination folder. Note the priority column shows the original Low priority. Result: Change in priority via filter action doesn't follow message if moved; will revert to original priority in destination folder display.
I think the root cause is that mozilla uses nsMsgHdr::SetPriority() to set mail priority. In this method, mozilla only change the corresponding UI when filter change a mail's priority. it doesn't notify IMAP server that the mail's priority has been changed. Actually, there are two kinds of priorities: 1. The priority set by user when composing an e-mail. 2. The priority set by filter after receiving an e-mail. The mail with the priority of 1, Priority is still there after moving from one folder to another. This is because server knows this. But for the second, The priority is lost after moving, because server doesn't know it.
Since Priority is a message header, there's no way to "notify" the imap server that the message priority has changed, short of removing the message, constructing a copy with the new message priority header, and uploading that message to the imap server. Or we could store Priority using user-defined keywords for those servers that support them. That's what we do for labels...
I think we can set the priority afte the mail is moved ( or copied). When copying is completed, nsImapMailFolder::OnCopyCompleted() will be called (assume it is a IMAP server). we can set priority here.
(In reply to comment #4) > I think we can set the priority afte the mail is moved ( or copied). > When copying is completed, nsImapMailFolder::OnCopyCompleted() will be called > (assume it is a IMAP server). we can set priority here. From my reading of the attachment in bug 261297, that patch should have fixed this bug. However, my recent test of bug 161658 showed that the Priority still was not being preserved on a move. Something is still wrong here.
Created attachment 184991 [details] [diff] [review] a proposal Move the patch of the bug 261297 to a new place. Because if IMAP server supports user flag i.e. if (! (supportedUserFlags & kImapMsgSupportUserFlag)) doesn't hold, the patch will take no effect.
(In reply to comment #3) > Since Priority is a message header, there's no way to "notify" the imap server > that the message priority has changed Does it actually make sense to allow changing the Priority header at all? That's altering the message as sent. Mozilla doesn't even *display* priority headers for the message, unless the column has been selected, so I'm having difficulty understanding the benefit. Perhaps this is to allow people to sort their priority-tagged messages and, when the important item of interest has been handled, remove the priority. If this is the justification for allowing that action, I would suggest a different means of handling it: leave the header as is, but add a flag to X-Mozilla-Status, and a menu (and filter action) for "Mark priority item as handled" or "Hide priority for this message". Then, in the priority column, the displayed status could read "handled" and sorted as "normal". (I suppose this would be extended to "low" priority messages as well, if such beasts actually exist.) If Priority is actually important, it should have an icon in the envelope panel (bug 81054) and that would be a logical place from which to hang such a UI. Note that there's a bug out there requesting an automatic filter action to label priority messages as "important".
David, do you still want this. And should patch be minused? (or review removed)
My first inclination is just to have people use tags instead of setting priority with message filters, but if this patch hasn't bit-rotted, I don't see the harm in taking it, since it's just moving some code around. I'll check if it still applies/works.
Created attachment 322193 [details] [diff] [review] tweaked patch same idea, but I moved the code inside the existing loop, but outside the userflag check, instead of adding a new loop.
Comment on attachment 322193 [details] [diff] [review] tweaked patch Ah, so the reason it works for me is that my server doesn't support user flags?
right - whoever wrote that code to set pending priority (and I have no reason to believe it wasn't me :-) ) just blindly put it with the rest of the code that set pending attributes, but that code was only needed for servers that don't support user flags.
checked in, thx for the original patch, Brian.