181561 - Changed priority via filter doesn't follow message if moved.

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[laurel]

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.

Comment 1

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 2

[Boying Lu]

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.

Comment 3

[David :Bienvenu]

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

Comment 4

[Boying Lu]

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.

Comment 5

[Howard Chu]

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

Comment 6

[Boying Lu]

Attachment: 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.

Comment 7

[Mike Cowperthwaite]

(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".

Comment 8

[Wayne Mery (:wsmwk)]

David, do you still want this. And should patch be minused? (or review removed)

Comment 9

[David :Bienvenu]

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.

Comment 10

[David :Bienvenu]

Attachment: 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 11

[[e-mail]]

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?

Comment 12

[David :Bienvenu]

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.

Comment 13

[David :Bienvenu]

checked in, thx for the original patch, Brian.