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.
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
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]
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
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]
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]
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.