358684 - A "stop processing filters" action to the custom filters

Status: RESOLVED FIXED

(MailNews Core :: Filters, enhancement)

Description

[Sergio]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; pt-BR; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; pt-BR; rv:1.8.1) Gecko/20061010 Firefox/2.0

This action makes the e-mail program get out of the current custom filters processing.

It happens that sometimes you don't want that "the next filter" being processed. As this action looks like a "return" or "break" it seems that it would not be so difficult to implement (I hope)...

This filter action is essencial...  Without it, undesired things happen during filters processing... 

Reproducible: Always

Comment 1

[Karsten Düsterloh]

Probably a dupe, but not sure of which of all those filter bugs...

Comment 2

[Karsten Düsterloh]

Attachment: Implement 'Stop Filter Execution' filter action (SM + TB), v1

This patch implements the 'Stop Filter Execution' filter action for IMAP, POP3, News and FilterAfterTheFact, incl. the relevant frontend fixes for both SM and TB.

Comment 3

[David :Bienvenu]

Comment on attachment 255729 [details] [diff] [review]
Implement 'Stop Filter Execution' filter action (SM + TB), v1

Thx very much for doing this, Karsten. One nit - can you make the variable names "move" and "copy" a little clearer - I think they're something like: listPosForCopies, listPosForMoves

Comment 4

[[e-mail]]

Comment on attachment 255729 [details] [diff] [review]
Implement 'Stop Filter Execution' filter action (SM + TB), v1

> NS_IMETHODIMP 
> nsMsgFilter::GetSortedActionList(nsISupportsArray *actionList)
> {
>+  // All the rules' actions form a unit, with no real order imposed.
Does this descriptive block belong before the function?

>+  // But certain actions like MoveToFolder or StopExecution would make us drop
>+  // consecutive actions, actions like AddTag implicitly care about the order
... , while actions like ...

>+  // of invocation. Hence we do as little reordering as possible, keeping the
>+  // user order as much as possible.
>+  // We explicitly don't allow for filters which do "tag message as Important,
>+  // copy it to another folder, tag it as To Do also, copy this different state
>+  // elsewhere".
[End of block here?] This can be done using two separate filters, right?

>+  // The order of actions returned by this method:
>+  //   index    action
action(s)?

>+  //     0      FetchBodyFromPop3Server
>+  //    1..n    all actions not specifically reordered, ordered as defined by user
"all other actions in their original order" perhaps?

>+  //  n+1..m    CopyToFolder rules
>+  //    m+1     MoveToFolder or Delete rule
>+  //    m+2     StopExecution rule
These are actions, and you have a column heading anyway ;-)

I was trying to think of a less confusing way to achieve this, however all I could come up with was a) use some system sort algorithm, e.g. quicksort (too much overhead to set up) b) give each filter action an action group, with each group having its own array, so that each action gets appended to the end of its group and you then concatenate all the groups (almost as much overhead).

Note: I haven't even tried compiling this, but I think it looks good.

Comment 5

[Karsten Düsterloh]

Attachment: addressed review comments; for checkin

Comment 6

[Karsten Düsterloh]

Landed on trunk.

Comment 7

[Karsten Düsterloh]

Note: "Version: Trunk" here still means 1.9.x, i.e. the fix will appear in SeaMonkey 2/Thunderbird 3.