87893 - Filters are not executed in order when action is Set Priority

Status: VERIFIED WONTFIX

(MailNews Core :: Filters, defect)

Description

[Håkan Waara]

Apparently, the whole behaviour is broken in that having a filter above another
in the filter-list should make us check that before all others, when using set
priority as action.

Real world example:

name="first"
enabled="yes"
type="1"
action="Change priority"
actionValue="Highest"
condition="OR (subject,contains,ris)"

name="second"
enabled="yes"
type="1"
action="Change priority"
actionValue="Lowest"
condition="OR (subject,contains,ris)"

Here we have two filters with the same criterium - if the subject contains "ris"
, do something.

Since the filter "first" is before "second", the message's priority should be
set to Highest, right? It's not.

When I tried, the priority became Lowest.

Comment 1

[Håkan Waara]

Might become dataloss if you have an advanced filtering system where one filter
takes care of something - and you have an underlying filter that takes care of
the unfiltered stuff (maybe delete it!).

Comment 2

[laurel]

That's because filters continue to evaluate until a move (move to folder or
delete) is done.  So after the match for the first filter, it continues to be
evaluated or "drops through" to the second filter... there it is set to Lowest
priority.  This is intended behavior by current (6.0 and 6.1) design.

Comment 3

[Håkan Waara]

Why would I want the filter after the first one to match??

I don't understand how this can be intended behaviour.

Comment 4

[Håkan Waara]

If this really is intended behaviour, I really think we should fix it.

Sspitzer, Bienvenu - comments?

Comment 5

[laurel]

Related/historical info in (verified, 6.0) bug 23590, including this excerpted
comment from David Bienvenu 2000-01-10 17:08 -------
"...  Now, due to incredibly heavy popular demand, we only stop evaluating
filters if a filter actually performs a move. Otherwise, we will keep evaluating
filters."

According to your scenario example, hwaara, this is an invalid point respecitve
to the current design... marking worksforme (since invalid always gets everyone
uptight).

Comment 6

[Håkan Waara]

At least give me the fair right to question this decision before you just slam a
invalid/worksforme in my face.

Comment 7

[laurel]

Come down off your pedestal.

Comment 8

[Håkan Waara]

Huh? In what way is it wrong of me to think that I have the right to discuss
this behaviour before you close the bug?

Comment 9

[Asa Dotzler [:asa]]

It is not unreasonable for hwaara to question this design.  This is a case where
the actual behavior deviates from the expected behavior (the reporter's expected
behavior) and that is how I define a type of bug.  It may be a bug which will
not be fixed but there are now two people on record who do not like the current
behavior and I think that warrants a reopening of the design discussion.  

Comment 10

[David :Bienvenu]

It's a perfectly valid resolution, and I'm marking it wontfix. People open bugs
when execution doesn't stop. People open bugs when execution does stop. It's a
no win solution for me to leave them all open. In the future, the solution will
be to allow the user to specify whether execution should stop or not, and that
is covered in another bug, which I will go look up when I get a chance.

Comment 11

[David :Bienvenu]

see bug 30081 - it covers the actual issue.

Comment 12

[Håkan Waara]

I agree. Fixing bug 30081 is the way to satisfy everyone. I will try to do that
then.

Comment 13

[laurel]

marking verified -- old invalid or wontfix resolutions