Last Comment Bug 181561 - Changed priority via filter doesn't follow message if moved.
: Changed priority via filter doesn't follow message if moved.
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: Filters (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.9
Assigned To: David :Bienvenu
:
Mentors:
Depends on: 261297
Blocks: 161658
  Show dependency treegraph
 
Reported: 2002-11-22 15:38 PST by laurel
Modified: 2008-07-31 04:30 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
a proposal (3.56 KB, patch)
2005-06-01 01:57 PDT, Boying Lu
no flags Details | Diff | Review
tweaked patch (3.55 KB, patch)
2008-05-22 16:33 PDT, David :Bienvenu
neil: superreview+
Details | Diff | Review

Description laurel 2002-11-22 15:38:37 PST
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 seth@sspitzer.org instead) 2003-05-08 11:45:21 PDT
mass re-assign.
Comment 2 Boying Lu 2004-09-02 22:40:27 PDT
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 2004-09-03 08:12:39 PDT
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 2004-09-06 20:11:16 PDT
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 2005-05-27 16:19:02 PDT
(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 2005-06-01 01:57:10 PDT
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.
Comment 7 Mike Cowperthwaite 2005-06-05 08:47:21 PDT
(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, NI for questions) 2008-02-01 04:27:25 PST
David, do you still want this. And should patch be minused? (or review removed)
Comment 9 David :Bienvenu 2008-05-21 16:04:34 PDT
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 2008-05-22 16:33:07 PDT
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 11 neil@parkwaycc.co.uk 2008-05-23 01:30:46 PDT
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 2008-05-23 07:15:51 PDT
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 2008-05-23 07:22:01 PDT
checked in, thx for the original patch, Brian.

Note You need to log in before you can comment on or make changes to this bug.