Closed Bug 181561 Opened 18 years ago Closed 12 years ago

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


(MailNews Core :: Filters, defect)

Not set


(Not tracked)



(Reporter: laurel, Assigned: Bienvenu)




(1 file, 1 obsolete file)

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.
mass re-assign.
Assignee: naving → sspitzer
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.
Product: MailNews → Core
(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.
Assignee: sspitzer → bienvenu
Depends on: 261297
Blocks: 161658
Attached patch a proposal (obsolete) — Splinter 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.
Attachment #184991 - Flags: review?(bienvenu)
(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)
QA Contact: laurel → filters
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.
Attached patch tweaked patchSplinter Review
same idea, but I moved the code inside the existing loop, but outside the userflag check, instead of adding a new loop.
Attachment #184991 - Attachment is obsolete: true
Attachment #322193 - Flags: superreview?(neil)
Attachment #184991 - Flags: review?(bienvenu)
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?
Attachment #322193 - Flags: superreview?(neil) → superreview+
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.
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.