1175822 - cascade filtering support

Status: RESOLVED WONTFIX

(Thunderbird :: Filters, enhancement)

Description

[grzegorz.szyszlo]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

currently I must duplicate many the same fields in different mail filters


Actual results:

It is no possibility for creating common filtering rules appliable to many different filters. When it is created many filters, it cause big cpu utilization


Expected results:

I need some cascade filters organized in tree, similar to directory & file structure.
Non leaf filters should only detect, mail is applicable or not. Leaf filter should be defined as currently defined filter, applying finally actions.
For example mails income from big mail group or any support or monitoring engine. Non leaf filter should be used first, and only decide mail is proper for other subfilters in its tree. for example this filter can define mail group addres detected by any field. subfiler can detect by subject, this is bug, info or witchlist. last leaf level of filters can decide, what action do based on that filtering, with additional depending on other fields.
This behavior should take less cpu utilization and handle less action. Currently it is needed configure all behavior in all detailed filters.

Comment 2

[Axel Grude [:realRaven]]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 297852 ***

Not quite sure if this is really a duplicate. I know it would "Kind of" be _prepared_ if we implemented my suggestions of "nesting filters", but that would still be a far way from it; one of the problems with nesting filters is that we do not currently have a proper "Primary Key" for filters so they are not really independent distinguishable entities, which is clearly a requirement for this one.

Comment 3

[:aceman]

I also do not think this is a dupe.
The enhancement here seems to propose to build one filter from other fragments of filters/rules (building blocks). It is not about AND/OR boolean operators, but to share rule fragments between multiple filters.

Comment 4

[Wayne Mery (:wsmwk)]

bug 323773 is the one I was thinking of

Comment 5

[grzegorz.szyszlo]

This is completly different approach of this problem. Traditionally we are focused on one filter, and apply inside this big logic rules (actually is available only one simple rule).
This approach cause, we still must duplicate most of decisions in dofferent rules.

My approach cause, we create bigger level filters that don't take final decision what to do.
But if you don't want implement this, sorry. It is your decision.
In my opinion this is feature will take big work, but this is one think I never seen in other mail clients, including commercial ones.

I changeg dubstatus from duplicate to wontfix because I see you don't want take this task, and this is not a duplicate.

Comment 6

[Wayne Mery (:wsmwk)]

Marking a bug as a duplicate is NOT saying that I or anyone wants to ignore.
And it  may be instructive to look at other bugs linked in bug 323773.

Perhaps an actual, fully coded example of what such a filter would look like would be helpful. And also, an example of or evidence of "big cpu utilization".

Comment 7

[Wayne Mery (:wsmwk)]

> Perhaps an actual, fully coded example of what such a filter would look like
> would be helpful. 
or Mock up or screen shot