Closed Bug 272963 Opened 15 years ago Closed 11 years ago

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

Categories

(MailNews Core :: Filters, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: jefdriesen, Assigned: rkent)

References

Details

Attachments

(1 file)

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:
*** Bug 272965 has been marked as a duplicate of this bug. ***
it is possible that the status flag is set after filters are run...
> 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. 

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.
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?!?
(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.
Status: UNCONFIRMED → NEW
Component: General → MailNews: Filters
Ever confirmed: true
OS: Windows XP → All
Product: Thunderbird → Core
Hardware: PC → All
Summary: Filter 'status is new' not applied automatically to incoming mail → Status of incoming mail is not set to 'new' before filtering can act on it
Version: unspecified → Trunk
*** Bug 350318 has been marked as a duplicate of this bug. ***
*** Bug 349890 has been marked as a duplicate of this bug. ***
(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.
Assignee: mscott → nobody
QA Contact: filters
Product: Core → MailNews Core
This will probably be fixed in bug 441932.
Status: NEW → ASSIGNED
Assignee: nobody → kent
Status: ASSIGNED → NEW
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.
Whiteboard: [has patch]
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.
Status: NEW → ASSIGNED
Attachment #381356 - Attachment description: The fix but I want to test more. → The fix.
Attachment #381356 - Flags: superreview?(bienvenu)
Attachment #381356 - Flags: review?(bienvenu)
Whiteboard: [has patch] → [needs r/sr bienvenu]
Blocks: 372372
Attachment #381356 - Flags: superreview?(bienvenu)
Attachment #381356 - Flags: superreview+
Attachment #381356 - Flags: review?(bienvenu)
Attachment #381356 - Flags: review+
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.
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.
Keywords: checkin-needed
Whiteboard: [needs r/sr bienvenu] → [needs checkin]
Comment on attachment 381356 [details] [diff] [review]
The fix.
[Checkin: Comment 15]


http://hg.mozilla.org/comm-central/rev/0cb63476f592
Attachment #381356 - Attachment description: The fix. → The fix. [Checkin: Comment 15]
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Target Milestone: --- → Thunderbird 3.0b4
Target Milestone: Thunderbird 3.0b4 → Thunderbird 3.0b3
Duplicate of this bug: 350318
You need to log in before you can comment on or make changes to this bug.