272963 - Status of incoming mail is not set to 'new' before filtering can act on it

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[Jef Driesen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: TB v0.9 (20041103)

The following filter is not applied automatically to incoming mail:

Match any of the following: 'Status is new'
Action: Move to folder

I'm using multiple POP3 accounts with the global inbox. The filter is assigned
to an individual account (not on 'Local Folders') and should run automatically.
The problem exist only for this specific rule. Other filters work perfect. Maybe
the 'status flag' is set after processing the filters? When the message is
delivered to the global inbox it has the correct flag 'new' and running the
filter manually does work.

I want to use this specific rule to move all email from one (of many) account to
a different folder. A workaround would be a third option in the filter dialog
(next to 'Match all of the following' and 'Match any of the following') named
'Match all messages'. Or something like that.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Jef Driesen]

*** Bug 272965 has been marked as a duplicate of this bug. ***

Comment 2

[David :Bienvenu]

it is possible that the status flag is set after filters are run...

Comment 3

[WADA:World Anti-bad-Duping Agency]

> I want to use this specific rule to move all email from one (of many) account to
a different folder.
A currently available workaround : 
  Use next conditions 
   - sender  doesn't contain "!#$%&'()0=~|@[`{+*};:]<>?_,./\"
   - subject doesn't contain "!#$%&'()0=~|@[`{+*};:]<>?_,./\"
  These are always TRUE execpt when spamer really sent such mail to you. 

Comment 4

[Brice Ruth]

This appears to still be a problem. I'm running version 1.0RC1 (20041201). I
have a filter that should set a label if the messages Status is NEW. However,
this never happens.

For me, it doesn't matter if I run the filter manually - unread messages
continue not to be labeled.

Comment 5

[Brice Ruth]

Furthermore, it seems as though a status of "NEW" is different than "Unread" -
in the sense that I have a view which filters based on something being "New" and
some messages that are "New" appear, but if I click out of that folder and back
into it, those messages no longer appear ... only messages that have newly
arrived now showup, not "Unread" messages in general.

Man alive! How do I setup a filter/view/search/etc. that hits unread messages?!?

Comment 6

[Mike Cowperthwaite]

(In reply to comment #2)
> it is possible that the status flag is set after filters are run...

Resummarizing the bug to that effect.  This is a Core issue.


(In reply to comment #5)
> How do I setup a filter/view/search/etc. that hits unread messages?!?

Filter for   Status, isn't, New  AND  Status, isn't, Read   AND .... 
for each of the available status values.  See bug 218853.

Comment 7

[Mike Cowperthwaite]

*** Bug 350318 has been marked as a duplicate of this bug. ***

Comment 8

[Mike Cowperthwaite]

*** Bug 349890 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

(In reply to comment #0)
> A workaround would be a third option in the filter dialog (next to 
> 'Match all of the following' and 'Match any of the following') named
> 'Match all messages'. Or something like that.

This has been done, btw: bug 66771.

Comment 10

[Kent James (:rkent)]

This will probably be fixed in bug 441932.

Comment 11

[Kent James (:rkent)]

Attachment: The fix. [Checkin: Comment 15]

This fixes the issue, plus has the added side benefit that the NEW flag could now be manipulated in a custom message filter action, which might have some advantages in controlling NEW as a notification method (though because we overload NEW to control filter plugins, that would have some serious side effects).

Because I am messing with the handling of the new flag, this fix could have some unintended side effects, so I want to test it for awhile before I try for review.

Comment 12

[Kent James (:rkent)]

I've run this for awhile, plus rechecked it, and I think it is OK, so I will ask for review.

The main motivation for this, now that the "match all messages" option is available, is to allow a filter action (probably custom through an addon) to manipulate the NEW flag. The NEW status is a useful (though often misunderstood) way to provide notification of the arrival of new messages, particularly if you want to use UNREAD as an indicator of an additional level of processing of the message. But some people might want to manipulate that in a filter, so that certain classes of incoming messages do not trigger a NEW flag. Currently I can manipulate the new message count, which is used for one class of notifications, but I cannot manipulate the NEW flag, in a custom filter action.

Comment 13

[David :Bienvenu]

Comment on attachment 381356 [details] [diff] [review]
The fix.
[Checkin: Comment 15]

messing with the handling of the new flag is always fraught with peril, but might as well get this in and try it out.

A unit test for this would be nice, particularly the filter on new aspect.

Comment 14

[Kent James (:rkent)]

I'll try to do a unit test for this soon. My new POP3Pump testing framework makes it very easy to write those, at least for POP3. But I'm still tweaking it on other bugs.

Comment 15

[Serge Gautherie (:sgautherie)]

Comment on attachment 381356 [details] [diff] [review]
The fix.
[Checkin: Comment 15]


http://hg.mozilla.org/comm-central/rev/0cb63476f592