Closed Bug 30081 Opened 21 years ago Closed 13 years ago
filter execution doesn't stop until matches a move/del - incompatible with 4
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" :-(
Reassign to bienvenu
Assignee: phil → bienvenu
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
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.
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
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
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.
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. ***
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
You need to log in before you can comment on or make changes to this bug.