User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Steps to reproduce: I have a bunch of email accounts, most of them POP3. Filtering rules can be defined only per each email account. This is very difficult to maintain and therefore I prefer to define for each email account a simple rule that moves any incoming message to Local Folders // Inbox. Then, I set up various rules on the latter folder to do various stuff with the messages (usually move to some other subfolder in Local Folders). This works great as long as I choose Local Folders // Inbox and run the filters manually (menu Tools // Run filters on folder). Actual results: When new email is received by the various email accounts, it is correctly moved to Local Folders // Inbox. However, the subsequent rules defined for Local Folders // Inbox are not triggered automatically and messages stay there. Expected results: Rules defined for Local Folders // Inbox should be run any time a new message appears in the Inbox, no matter if it is "incoming" or "moved to" or "copied to" or even manually "dragged & dropped" message. At the moment, it seems that rules are applied only to "incoming" messages.
I think this works as designed and there is no secondary trigger.
Yep, that is what I was afraid of. As an alternative to my use case, it might help if it is possible to define rules, which process incoming email of all existing accounts.
A rule is linked to an account, but nothing stops you defining the same rule again for another account. Magnus, WONTFIX on this or enhancement? As far as I have seen the filter execution, it's really linked to incoming mail. So if an incoming message is moved to a folder, no secondary filters are triggered for that folder. Mind you, this could be used to hang TB by defining rules that move message to a folder and from there back to the original folder, triggering the same move again. Changing this would be a huge effort (incl. detecting deadlock situations, see previous paragraph) and given the current resources, WONTFIX and enhancement will come to the same here: It won't be implemented.
I agree with WONTFIX re. the secondary triggering of rules. How about a feature request to have a rule applicable for all accounts? (Managing rules per account is difficult. Applying filters - per user's choice - sounds to me as expected behaviour and I was confused, that TB does not do so - see also the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1294092 which further complicates the setup.) If not, I would probably try to write a script which would synchronise all the msgFilterRules.dat files across accounts via cron job or file change trigger, but that would be a bit weird solution... (Unfortunately, I cannot really code to help getting this implemented in TB.)
Global filters is bug 34973 which is complicated since different types of accounts offer different possibilities.
Severity: normal → enhancement
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Summary: Cannot apply message filtering rule in folder, which is target one of another "move" rule. → Cannot apply message filtering rule in folder, any time a new message appears in that folder (moved by other filter action)
In "Bug 864187 - Run filters periodically" I had proposed a new filter type, that would essentially automate the regular application of Run Filters Manually on folders. That would have allowed resolution of the OPs issue here. Unfortunately it go bogged down in the larger issues of per account/per folder for filters. That is a real issue, one that I normally workaround with a "Folder Name" search term (which is a FiltaQuilla feature). In the IMAP case, again there is an advanced feature that you typically need FiltaQuilla to enable which is a form of secondary filter application, which is "Apply Incoming Filters". Typically that is used when a server filter moves a message to an IMAP folder, but should be processed by Thunderbird filters as well. The proposal here is similar, except it involves a cross-account move to the local inbox, rather than a move to a non-inbox folder within the same account. The issues are similar though, namely that it is easy to setup filter loops which are quite destructive if you are not careful. In some sort of grand filter rewrite, we would probably incorporate some sort of explicit anti-looping feature that would allow this kind of thing for the casual user. For the current advanced user, who can accept the risk of loops for the benefit of more sophisticated message processing, it should still be possible to do this somehow. To me though that means extension. So I would probably morph this into a request that this feature be enabled under a hidden preference, to protect the unsuspecting causal user from filter loops. But not everyone likes hidden preferences (which can be exposed in an extension for advanced users).
There is also bug 294632.
You need to log in before you can comment on or make changes to this bug.