All users were logged out of Bugzilla on October 13th, 2018
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)
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.
Great proposal, confirming. Though this doesn't really belong to frontend, and might even be appropriate to move to Mozilla Suite.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing the summary to better reflect the contents (added "Hierarchical")
Summary: Message Filter Proposals → Hierarchical Message Filtering Proposals
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 :(
You need to log in before you can comment on or make changes to this bug.