Closed Bug 232569 Opened 21 years ago Closed 8 years ago

"move to folder" does not stop subsequent filter rules, if the mail is already held in the move target folder(ie. Run filter on this target folder)

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: World, Unassigned)

References

(Depends on 1 open bug)

Details

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040128

Message filter ignores "move to folder" condition if the mail is already placed
in move target folder.
This causes difficulty in re-categorizing of already filtered mails.

Reproducible: Always
Steps to Reproduce:




1. Create filters of following rules.
 (Filter-A) IF  Sender contains "aaa-"
            AND Sender contains "@xxx.yyy" THEN move to folder "A"
 (Filter-B) ELSE IF  Sender contains "bbb-"
            AND Sender contains "@xxx.yyy" THEN move to folder "B"
 (Filter-OTHER)
            ELSE IF Sender contains "@xxx.yyy"
                    THEN move to folder "OTHER"  

  Purpose of the filters are ;
    - Mails from "aaa-....@xxx.yyy" => folder "A"
    - Mails from "bbb-....@xxx.yyy" => folder "B"
    - Other mails from "@xxx.yyy" domain => folder "OTHER"

2. If mails are placed in other than folder "A" or "B", "run filter on folder"
works well.

3. After mails are separated to folder "A"/"B"/"OTHERS" successfully, "run
filter on folder" on folder "A" moves all mails in folder "A" to "OTHERS" and
"run filter on folder on "B" moves all mails in folder "B" to "OTHERS".
This is because message filter does not fire "move folder" condition if  the
mail is already placed in target folder of "move to folder" action.
 
This situation will not occur if "Filter-OTHER" type filter is not defined.
This situation can also be avoided by changing "Filter-OTHER" to rules like
'Sender contains "@xxx.yyy" but does not contain "aaa-" nor "bbb-"'.
But this is redundunt.
This situation can be easily recovered by "run filter on folder" on "OTHERS" again.
However, if many mails are saved in a folder, re-filtering takes long time.

Message filter should fire "move to folder" condition if the mail is already
placed in target folder and should terminate following filter application.
I don't think the reason is exactly that 'message filter does not fire "move 
folder" condition if the mail is already placed in target folder' -- I think 
that what happens is, running filters at a given time (either for enabled 
filters on newly arriving mail, or for selected filters on a specific folder):
whichever filters are set up to run, are *all* run on the message until such 
point as the message is no longer available (that is, moved elsewhere).  There 
is no test while running the filters of "Has this message been processed 
already?"

Therefore, I'm not sure this is a bug.  It could be a valid enhancement request 
for that sort of logic -- or perhaps for a specific filter action of "End 
filtering of this message."
(In reply to comment #1)

> I don't think the reason is exactly that 'message filter does not fire "move 
> folder" condition if the mail is already placed in target folder'

My 'message filter does not fire "move folder" condition if the mail is already
placed in target folder' means that Message filter does not consider "move to
folder"(this is the final action of the filter) is completed when the mail is
already placed in the target folder.
Sorry for my confsusing description.

Following rules application on the mail should be stopped when the mail is
already placed in the target folder.
Summary: Message filter ignores "move to folder"condition if the mail is already placed in move target folder → Message filter does not consider that "move to folder is satisfied"if the mail is already placed in the target folder of "move" action
Product: MailNews → Core
Change Summary to more appropiate one.
Summary: Message filter does not consider that "move to folder is satisfied"if the mail is already placed in the target folder of "move" action → When "Run Filter on folder", if a mail is already held in a folder, message filter which moves to the folder is ignored, then the mail is moved to another folder if another rule which moves the mail to other folder is defined
Summary: When "Run Filter on folder", if a mail is already held in a folder, message filter which moves to the folder is ignored, then the mail is moved to another folder if another rule which moves the mail to other folder is defined → then the mail is moved to another folder if another rule which moves the mail to another folder is defined after the ignored rule When a mail is already held in move target folder(ie. Run filter on this folder), message filter which moves to this folder i…
*** Bug 272240 has been marked as a duplicate of this bug. ***
Change summary(shorten)

(New)
"move to folder" does not stop subsequent filter rules, if the mail is already
held in the move target folder(ie. Run filter on this target folder)

(Old)
When a mail is already held in move target folder(ie. Run filter on this
folder), message filter which moves to this folder is ignored(not stops), then
the mail is moved to another folder if another rule which moves the mail to
another folder is defined after the ignored rule
Summary: then the mail is moved to another folder if another rule which moves the mail to another folder is defined after the ignored rule When a mail is already held in move target folder(ie. Run filter on this folder), message filter which moves to this folder i… → "move to folder" does not stop subsequent filter rules, if the mail is already held in the move target folder(ie. Run filter on this target folder)
Confirm by myself according to DUPed bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Tested with Thunderbird trunk 2007/8/22 build.
 Mails :  2 mails of "Subject :test", To: xxx@yyy
          mail-1 : Subject: test, To: xxx@yyy, CC: ppp@qqq
          mail-2 : Subject: test, To: xxx@yyy  (No CC: header)
 (Case-1) rule-1 : If subject is "t" Then move to folder-1
          rule-2 : If subject is "e" Then move to folder-2
 (Result-1)
   (1-1) When all mails are in folder-1 : All mails are held in folder-1
   (1-2) When all mails are in folder-2 : All mails are moved to folder-1
 (Case-2) rule-1 : If to contains xxx Then move to folder-1
          rule-2 : If to contains yyy Then move to folder-2
 (Result-2) Same result as Case-1.
 (Case-3) 1. If cc contains ppp Then move to folder-1
          2. If to contains xxx then move to folder-2
 (Result-3)
   (3-1) When all mails are in folder-1 :
         All mails are held in folder-1.
         Filter log says that mail-1 hits to rule-1,
         but no log for rule-2/mail-2
   (1-2) When all mails are in folder-2 :
         mail-1 is moved to folder-1, and mail-2 is kept in folder-2.
         Filter log says "mail-1 hits to rule-1, and mail-2 hits to rule-2.

This bug is still re-created with Tb 2.0.0.6, but it seems that this bug is already fixed by trunk (Bug 382051 looks to be remained problem on IMAP after fixing).
Based on Result-1 & Result-2, closing as WORKSFORME.

I'll open separate bug for Result-3.
(False negative when CC:, seems to be similar issue to Bug 389006)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I've opened Bug 393668 for above problem of Result-3.
Product: Core → MailNews Core
This bug is observed in Thunderbird 45.5.0 again.
Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Blocks: 1215933
See Also: → 393668
Regressin in Thunderbird 45 was new regression between thunderbird-37.0a1 2014-12-20 and thunderbird-37.0a1 2014-12-21.
Close this bug for old Thunderbird as WORKSFOME again.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 8 years ago
Resolution: --- → WORKSFORME
Blocks: 1320676
No longer blocks: 1320676
Depends on: 1320676
No longer blocks: 1215933
You need to log in before you can comment on or make changes to this bug.