Closed Bug 30081 Opened 21 years ago Closed 13 years ago

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

Categories

(MailNews Core :: Backend, defect, P3)

x86
Other
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 174441
Future

People

(Reporter: selmer, Assigned: Bienvenu)

References

Details

(Whiteboard: relnote-user)

Attachments

(1 file)

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" :-(
QA Contact: lchiang → laurel
Reassign to bienvenu
Assignee: phil → bienvenu
IMAP, POP?
changing summary to reflect bug.
Status: NEW → ASSIGNED
Summary: Filter not working → change priority Filter not working
works fine for me. Laurel, does this work for you? This is for IMAP, BTW.
Summary: change priority Filter not working → change priority Filter not working for IMAP
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.
By the way, I migrated the IMAP profile (and therefore the rules.dat) with
current build from 4.x 
Attached file rules.dat file
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?
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.
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.)
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.
Summary: change priority Filter not working for IMAP → execution doesn't stop - incompatible with 4.5
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?
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.
Keywords: relnote
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.
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 :-)
oh, you're right. Somehow, I didn't see all of Sol's comments :-( how 
embarrasing.
moving to m20 - may not fix.
Target Milestone: --- → M20
Keywords: relnoterelnote2
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.
I agree that a per-filter option is the way to go, but not for 6.0
Target Milestone: M20 → Future
Keywords: relnote2relnote
Whiteboard: relnote-user
Keywords: relnoterelnoteRTM
Added to the "Upgrading to Netscape 6" document
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.
Keywords: relnote
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. :)
*** Bug 124073 has been marked as a duplicate of this bug. ***
Please change someone the summary of this bug because it's hard to find.
Summary: execution doesn't stop - incompatible with 4.5 → filter execution doesn't stop until matches a move/del - incompatible with 4.5
*** Bug 186021 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
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.
this is fixed now that we have a stop filter action - so duping.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 174441
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.