A "stop processing filters" action to the custom filters



MailNews Core
11 years ago
9 years ago


(Reporter: Sergio, Assigned: Karsten Düsterloh)


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



11 years ago
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

11 years ago
Probably a dupe, but not sure of which of all those filter bugs...
Assignee: mscott → nobody
Component: General → MailNews: Backend
Ever confirmed: true
OS: Windows 2000 → All
Product: Thunderbird → Core
QA Contact: general → backend
Hardware: PC → All
Version: unspecified → Trunk


11 years ago
Component: MailNews: Backend → MailNews: Filters
QA Contact: backend → filters

Comment 2

11 years ago
Created attachment 255729 [details] [diff] [review]
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.
Assignee: nobody → mnyromyr
Attachment #255729 - Flags: superreview?(bienvenu)
Attachment #255729 - Flags: review?(neil)

Comment 3

11 years ago
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
Attachment #255729 - Flags: superreview?(bienvenu) → superreview+

Comment 4

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

> 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

>+  //     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.
Attachment #255729 - Flags: review?(neil) → review+

Comment 5

11 years ago
Created attachment 255938 [details] [diff] [review]
addressed review comments; for checkin
Attachment #255729 - Attachment is obsolete: true
Attachment #255938 - Flags: superreview+
Attachment #255938 - Flags: review+

Comment 6

11 years ago
Landed on trunk.
Last Resolved: 11 years ago
Resolution: --- → FIXED
Product: Core → MailNews Core

Comment 7

9 years ago
Note: "Version: Trunk" here still means 1.9.x, i.e. the fix will appear in SeaMonkey 2/Thunderbird 3.
You need to log in before you can comment on or make changes to this bug.