263441 - Hierarchical Message Filtering Proposals

Status: NEW

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Andrew Morgan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

1. Right-click message has option "Create Filter" which would populate the
filter criteria automatically.

2. Hierarchical message filters.

The basic idea is to implement a tree instead of a flat list.  This supports
multi-stage filtering.  For example:

- Root (no criteria)
|_ - Software (just a classification node - no criteria)
   |_ - IBM (move from [Inbox] sender contains "@*ibm.com" to [IBM]) (wildcard!)
      |_ + Canada (move from [IBM] sender contains "@ca." to [Canada]
      |_ - US
         |_ - Development (just a classification node - no criteria)
            |_ Joe (move from [IBM] sender contains "joe@" to [Joe])
            |_ Bob (move from [IBM] sender contains "bob@" to [Bob])
         |_ - Marketing (just a classification node - no criteria)
            |_ Jack (move from [IBM] sender contains "jack@" to [Jack])
            |_ Jane (move from [IBM] sender contains "jane@" to [Jane])
|_ - Hardware (just a classification node - no criteria)
   |_ - HP (move from [Inbox] sender contains "@*hp.com" to [HP]) (wildcard!)
      |_ - Sales (just a classification node - no criteria)
         |_ Jack (move from [HP] sender contains "jack@" to [Jack] (different))


Reproducible: Always
Steps to Reproduce:
N/A
Actual Results:  
N/A

Expected Results:  
N/A

Benefits of hierarchical filtering:

1. Multi-stage
* Incoming mail from IBM ends up in the IBM folder.
* Known mail from IBM is filtered in a subsequent step moving the mail from IBM
to a valid folder (not necessarily below IBM, eg Junk)
* Unknown mail from IBM ends up in the IBM folder instead of the InBox
* Delivery failures/blocked mail from IBM ends up in the IBM folder instead of
the InBox.
* Subsequent filtering steps operate on the folder of the most recent ancestor
instead of the InBox (a child filter of IBM operates on the IBM folder; a child
filter of Joe operates on the Joe folder).  Since "Software" is a purely
organizational node, its child filters operate on the InBox (most recent ancestor).

2. Easy filter creation
* Right-clicking the unknown mail and choosing "Create Filter" would populate
the new filter dialog with most criteria including the the parent of the new
folder, and position the rule properly in the filter tree.

3. Easy navigation of the Message Filter dialog
* My filter dialogue contains 60 rules (which I sort alphabetically manually!)
and is becoming unmanageable to maintain.

4. Filter rules can be cut out and pasted somewhere else.  This allow arbitrary
re-classification.  For example, I may wish to introduce the distinction between
work software and leisure software.  I could add "Work" and "Leisure" nodes
below software (no criteria).  I could then cut IBM from Software and paste
below "Work".  Since there are no real criteria between InBox and IBM, this
filter still operates on the InBox.

5. The filter dialog would need to include a search function.

The more I think about it, the more I realise that the filter tree structure
looks like the folder tree structure.  Perhaps an idea is to right-click the
folder and apply criteria there.  The multi-stage filtering can happen as the
tree is traversed top to bottom.  The point is that mail is moved in a number of
simple steps, rather than a few complicated steps.

Mail containing:
"@*ibm.com" moves to IBM.
"@ca." moves from IBM to Canada.
"joe@" moves from IBM to Joe.

Unknown IBM mail is in IBM folder (instead of InBox)
Unknown IBM Canada mail is in Canada folder (instead on InBox)

Comment 1

[David A. Cobb]

Could this be related to [my] Bug#241576 ? 
It looks much like the same sort of problem -- handling of "unexpected" byte
values occurring in the folder names or filter names (both have bitten me).

It's not a dupe, but maybe a clue to where the problems are.

Comment 2

[Alexey Chernyak]

Great proposal, confirming.

Though this doesn't really belong to frontend, and might even be appropriate to
move to Mozilla Suite.

Comment 3

[David Fraser]

Changing the summary to better reflect the contents (added "Hierarchical")

Comment 4

[grzegorz.szyszlo]

Great idea. I suggest implement something simple at start.
1. Implement wildcard filtering. At now I cannot make simple filter for mail with title:
   "Some system send bug 123 for you", when 123 is variable number.
I suggest implement this as fs wildcards, eg. ? and * like dir/ls filtering,
and regexp filtering. Libaries are available and commonly in using.
At now the most users must use multiple condition, like "start with", "end with", "contains" etc. I suggest add "wildcard" and "regexp"

2. Implement comparation *after* email address extract. Actually when email is formated with multiple RFC's manners, it contains some extra fields and codepages. I suggest extract bare email and this compare with filter stings.

Others, like tree stack filter I suggest implement later.

So. why this is waiting so long? Suggestion incomed at 2000 year, now is 2013 !!!! This is like 10 years roadmap in communist regime :(