30081 - filter execution doesn't stop until matches a move/del - incompatible with 4.5

Status: RESOLVED DUPLICATE of bug 174441

(MailNews Core :: Backend, defect, P3)

Description

[selmer (gone)]

I have a migrated profile.  It has a rules.dat file that has been working
correctly under 4.x for quite some time.  In Seamonkey, it does not correctly
classify my mail.  In particular, I have a rule right at the top of the list
that sets the priority of all mail (from,contains,jar) to highest priority.  In
the 2000-02-27-08 build, it got priority "lowest" :-(

Comment 1

[Phil Peterson]

Reassign to bienvenu

Comment 2

[David :Bienvenu]

IMAP, POP?

Comment 3

[David :Bienvenu]

changing summary to reflect bug.

Comment 4

[David :Bienvenu]

works fine for me. Laurel, does this work for you? This is for IMAP, BTW.

Comment 5

[laurel]

Change priority to highest based on from contains laurel works fine for me using
IMAP with linux rh6.0 and NT 4.0 on mar16 commercial beta builds.  

I'll keep trying varied priority filters, but basically working ok for me.

Comment 6

[laurel]

By the way, I migrated the IMAP profile (and therefore the rules.dat) with
current build from 4.x 

Comment 7

[selmer (gone)]

Attachment: rules.dat file

Comment 8

[selmer (gone)]

I've attached the rules.dat file I use.  Is it possible that some particular 
rule or combination of rules is causing the problem I've seen?

Comment 9

[David :Bienvenu]

Yes, due to popular demand, I got rid of the behaviour that subsequent filters 
don't get applied if a previous filter does get applied. (People wanted 
multiple filter actions - this is a cheap way of doing that.) Now, I only stop 
if a filter moves a message. So, your highest priority and your lowest priority 
filters are both firing. I could just turn off the ability to execute multiple 
filters and piss those people off, or I could leave it the way it is and piss 
off users who counted on that behaviour. Or, I could make it optional, either 
on a global or per-filter basis. Any of these would be way down the list of my 
priorities.

Comment 10

[selmer (gone)]

Aha!

Personally, I would have preferred to have multiple rules working in 4.x :-)  
However, this change means that my migrated profile doesn't behave the same way 
it did when I created it on 4.x.  I think you should reconsider the priority of 
giving the option and make the old behavior the default (especially if doing 
otherwise breaks my laboriously created rules.)

Comment 11

[David :Bienvenu]

Oh, well, more people have complained about the old way it worked, so I guess 
I'm screwed. I can't justify spending much time on a feature that doesn't even 
have a UI, so I guess I'll put it back the way it was.

Comment 12

[selmer (gone)]

Sorry if I hit a nerve.  I was more thinking that a pref could be used to 
control this.  The UI for filters seems like an important feature for beta 2, so 
I kinda expected you'd have UI for this too at the same time...

Sol, do we have any data on how many people would even notice?

Comment 13

[sol]

I have no data on this.

Here's what I know, however. Filters are a relatively "advanced" feature - the 
majority of users I've observed or spoken to (outside of Netscape) never set 
filters. However, the people that do use filters depend heavily upon them.

I would not expose a preference that allows (a) filters to stop firing after the 
first filter is tripped, or (b) filters to continue firing until a move 
operation is encountered. The % of users who would understand this choice is 
really small.

I would recommend that we leave things alone for Beta 1, perhaps include 
something in the release notes that explains how we have "improved" the behavior 
of filters, and then see if we hear any/much negative feedback regarding the new 
behavior.

I added "relnote" as a keyword so we can tell users that filters will keep on 
firing.

Comment 14

[David :Bienvenu]

I agree with Sol - that matches the data I have. Probably the best thing to do
is punt, put the behaviour back to 4.5, and file a help wanted enhancement
request for the behaviour that there was so much clamouring for. If they really
care, they can do it themselves.

Comment 15

[selmer (gone)]

David,

Sol's comments agreed with your original take that you should leave the change 
in place.  Given what he said, I agree with that (since I also like the new 
behavior :-)

Comment 16

[David :Bienvenu]

oh, you're right. Somehow, I didn't see all of Sol's comments :-( how 
embarrasing.

Comment 17

[David :Bienvenu]

moving to m20 - may not fix.

Comment 18

[Matthew Tuck [:CodeMachine]]

You could add an option to this that says "don't check further filter rules" in
the action section.  This should be easily to understand than a global
preference.

If I didn't highly suspect this was too late for RTM, I'd say it'd be good to
automatically use the previous behaviour for old rules, but make the new one the
default for new rules.

Comment 19

[David :Bienvenu]

I agree that a per-filter option is the way to go, but not for 6.0

Comment 20

[Kristi Fredrickson]

Added to the "Upgrading to Netscape 6" document

Comment 21

[timeless]

please add a relnote for this to the mozilla releases, I'm assuming that the 
netscape releasenote is usable, otherwise QA or text here should be able to 
describe it. I just searched through 0.9.1 relnotes and this was not listed. 
Thank you.

Comment 22

[Håkan Waara]

I was about to implement this, because I'm like one of you people on the CC list
that wants this badly... However, considering how the Filters UI currently looks
(way, way too difficult to use IMHO) I'm not sure Yet Another widget is healthy
for this poor window.

On the other hand, it's yet another reason to implement multiple actions. :)

Comment 23

[laurel]

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

Comment 24

[OstGote!]

Please change someone the summary of this bug because it's hard to find.

Comment 25

[laurel]

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

Comment 26

[TGOS]

The fall-through concept is *sane*! Filter execution shouldn't stop, just
because a filter matches. 

E.g. I want to do one thing with all mails marked as importand and another thing
with all mails from a certain address. Since it doesn't stop, I have two rules;
one may match, the other one, both or none. 

If it stopped after the first match, I would have to write four rules, just for
the same behavior, to catch all four possible combinations!

Think about the case of 4 rules in a row. If it stopped after the first match, 4
rules must be replaced by 16!!! So the current behavior is perfect.

What is missinng is an action named "Stop further filter evaluation" or so. If
you change the bug's subject line accordingly, I will vote for this bug, because
sometimes even I want that the execution stops, although there was no move or
delete action.

Comment 27

[David :Bienvenu]

this is fixed now that we have a stop filter action - so duping.