Open Bug 294632 Opened 20 years ago Updated 1 year ago

Filters should be per-Folder, not per-Account - Filter on non-Inbox folders

Categories

(MailNews Core :: Filters, enhancement)

Product:
MailNews Core
Component:
Filters
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: hyc, Unassigned)

References

(Blocks 6 open bugs)

Details

(Whiteboard: [filter-mgmt])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050516 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050516 Currently it appears that filters only run automatically on the Inbox of the account for which they're defined. It would be nice to be able to assign filters to arbitrary folders that trigger whenever any message arrives in that folder. For example, I have a couple filters that I have to manually run on my Trash Folder: Delete partial messages, and Delete messages older than 30 days. I have to remember to run these or my Trash folder keeps growing over time. (And I don't want to just Empty the trash on a schedule.) I think this solution would also clean up some of the headache of using filters with a Global Inbox - if you associate filters with folders instead of accounts, you can do everything in the Global Inbox and there's no hassles. Reproducible: Always
Now I see there are a number of other bugs regarding how filters are scoped. It looks like they need to be hierarchical: Per-profile filters - global across all accounts Per-account filters - global across all folders in an account Per-folder filters - unique to a single folder I still use separate Inboxes for my separate accounts, so while setting up filters in a Global Inbox might solve the global requirement for some people, it's not a complete solution. And it's rather annoying to have to enter the identical filter across multiple accounts when you need the feature everywhere. I'm not sure what would be an appropriate UI or backend implementation for this. I guess we can continue to use a per-account msgRules.dat file, and add a label to indicate that certain filters are only for certain folders. But we should add a per-profile msgRules.dat file for global filters as well. I think the Filter Editor window should only show you the filters that are in effect for the currently select context. If you have a folder selected, it will show all of the profile, account, and folder filters for the current folder. If you have an account selected but no folder, then you will only see profile and account filters. If you have no account selected, then you'll only see profile filters. I'm tempted to say that editing should be disabled on filters if you're in the wrong context, but that might just be too annoying. (E.g., if you're in a folder, you can see the profile and account filters, but not modify them.) Likewise when creating new filters, they should by default go into your current context, though I guess it would be friendly to have a selector for that.
Blocks: 281300
Blocks: 281643
I guess this is bug 34973. Some of these requests are truly ancient. *** This bug has been marked as a duplicate of 34973 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Blocks: 257979
Blocks: 257415
Blocks: 180196
The idea of automatically deleting messages from Trash actually has a bug all its own, as a feature outside the filtering context: bug 11055. (I don't understand what "delete partial messages" means.) Given that, I don't see what's gained with per-folder filters. Would these be applied to messages arriving in a particular folder (meaning that IMAP server filtering is already in use)? Then what does the filter do that the server-side filter couldn't? Or are they intended to be run when any client-level filter redirects a message to a particular folder? This means filter chaining, which I think is getting needlessly complex. I think bug 34973 is valid, and I think the simple way to implement that is to have an Account criterion available when defining filters; and if the criterion is not specified, then it applies to all incoming (mail) messages. (I don't think that a "global" filter should be applied to News or RSS unless explicitly dictated in the filter criteria.) But I don't see a use of per-folder filtering.
(In reply to comment #3) > The idea of automatically deleting messages from Trash actually has a bug all > its own, as a feature outside the filtering context: bug 11055. (I don't > understand what "delete partial messages" means.) re: partial messages - I run POP3 with "Fetch Headers Only". A "Partial message" is the header stub message that gets downloaded before selecting a full body download. > Given that, I don't see what's gained with per-folder filters. Would these be > applied to messages arriving in a particular folder (meaning that IMAP server > filtering is already in use)? Then what does the filter do that the server-side > filter couldn't? In the context of unified spam/user filters, the local filters can do spam filtering that may not have occurred on the server. Whether that's important or not is not a question I'll address here. Certainly David thinks it's a good thing that the spam filter is run on folders when they get accessed. > Or are they intended to be run when any client-level filter redirects a message > to a particular folder? This means filter chaining, which I think is getting > needlessly complex. It might mean filter chaining. I agree that that could be complex, but to call it "needless" before examining all the uses is premature. It can also have other simpler, valid applications, such as redirecting outbound messages that were copied to the Sent folder. > I think bug 34973 is valid, and I think the simple way to implement that is to > have an Account criterion available when defining filters; and if the criterion > is not specified, then it applies to all incoming (mail) messages. (I don't > think that a "global" filter should be applied to News or RSS unless explicitly > dictated in the filter criteria.) re: "Global" filters vs News/RSS - that's fair. And the notion of specifying a list of accounts for filters is reasonable, but that doesn't provide enough granularity to resolve as many of the enhancement requests as you could. People also want to be able to select that certain folders Opt Out of spam filtering. So again, you need a mechanism for specifying folder-specific filtering, and when spam and user filters are unified, that naturally leads to specifying folder specific filters in general. > But I don't see a use of per-folder filtering. You haven't looked at the problem from a wide enough perspective yet.
(In reply to comment #3) > The idea of automatically deleting messages from Trash actually has a bug all > its own, as a feature outside the filtering context: bug 11055. (I don't > understand what "delete partial messages" means.) And while I am happy to see that bug is now resolved, it still shows that patches are being applied with too much tunnel vision, doing one-offs to solve single problems instead of taking a good look at all the outstanding requests, identifying what they have in common, and solving the root issue. Kill as many birds as possible with a single stone, lord knows the project doesn't have a lot of stones to go around. E.g. bug 59365 - filters should have triggers. The fix for bug 11055 essentially creates all the framework to autoexecute filters whenever a folder is opened, but it falls short because all it allows you to do is delete messages based on age. The fix for 11055 should be generalized to use the filter mechanism to allow any message selection criteria and any action - delete messages, or move them to another folder for archiving purposes, whatever. > But I don't see a use of per-folder filtering. Bug 34973 - wants global filters, bug 129883 - wants filters sharable across accounts. I think the patch in 129883 (which was rejected) is the wrong approach, but it is basically trying to solve the same problem as bug 34973. And my suggestion here would address both needs without wasteful duplication/copying of filter rules between accounts. Also, implementing the single feature I describe here would automatically solve bug 180196 (filter on sending, just set up filters on your Sent folder), bug 257979, bug 257415, and bug 281643 (filter on delete - just setup filters on the Trash folder). (Bug 226422 would also be mostly solved.)
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → EXPIRED
(In reply to comment #7) > This bug has been automatically resolved after a period of inactivity (see above > comment). If anyone thinks this is incorrect, they should feel free to reopen it. I believe this issue is still important, but apparently no one else shares this view. I don't have the time to write the patch at the moment, nor the inclination to make time given how slowly my other patches have been responded to, so I'll leave this bug closed.
I agree that this bug should be considered. For most of the users it is totally unclear why filters do not automatically run for the Global Inbox. This is really user unfriendly!!
Reopening because there is another bug about to be duped to this.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
*** Bug 321296 has been marked as a duplicate of this bug. ***
*** Bug 323163 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 323163 has been marked as a duplicate of this bug. *** From my comments in that bug: > The filter options would be to: > * run filter on messages newly added to folder (checkbox) > * run filters at start of session (radio button) > * run filters every n days (radio button) > for people who leave client open all the time > * run manually only (radio button) What would make this a killer feature is also taking care of Bug 80439, which is an RFE for the ability to run external programs as filters. I'd be really happy to have a script which does all sorts of intelligent filtering on specialized mailing lists in folders.
(In reply to comment #13) > > The filter options would be to: > > * run filter on messages newly added to folder (checkbox) > > * run filters at start of session (radio button) > > * run filters every n days (radio button) > > for people who leave client open all the time > > * run manually only (radio button) Filter triggers, bug 59365
*** Bug 328045 has been marked as a duplicate of this bug. ***
See also Bug #257729 - "Run Mail Filters When Sending Mail".
Bug #11039 "Filter outgoing messages" is an even older version of that bug.
No longer blocks: 180196
Confirming this bug because I want filters to automatically run when emails are redirected to my local folders/subfolders. For instance, my Gmail account has a filter which redirects all requests for review in my local Reviews folder. Then I want to be able to set filters in this local folder which tags incoming requests for review based on who is the requestee (e.g. me).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
I am for this bug because I like to keep an Archive folder of all my messages (similar to the way Gmail does it). I would like to have a filter on the Inbox that copies all incoming messages to the Archive folder and a similar filter on the Sent folder and then another filter on the Archive folder that marks everything as read, since it is still unread when it gets copied from the Inbox. Currently, the best I can do is have the Inbox messages copied to Archive. the rest I have to do manually.
Aaron, in your message filter, you can specify multiple actions. In addition to copying the message to the Archive folder, you can also add "Mark as read". This will do what you want.
I tried that, but it just ends up marking the messages in my Inbox as read, which is not what I want.
Hmm... maybe it's because you're copying messages instead of moving them. I would test that. I would also try download the latest version, maybe even a nightly, and try it again. It sounds like you've found a completely different bug.
Obviously if I do move it won't leave the message in my Inbox unread because it's not leaving the message in my Inbox. I checked the filter logs and it seems that it is applying the Mark as Read before the Copy, even though I put Copy first. I'm not sure that that means anything, because logically, a single filter should be applying to just one message, so the expected result would be that the message in the Inbox is marked as read and the copied message is not marked as read. In practice, however, both are marked as read, since the message is marked as read before it is copied.
Why isn't this implemented similarly to Apple's Mail? By default all filters are global and you can narrow the filter scope by adding extra parameters. So the extra parameters could specify the target folder or account. With this model, filters would automatically be transferable from one account to another which is currently impossible to do. Come on people, I can't believe this thing has been around since 2000, what the heck is going on?
Why isn't this implemented similarly to Apple's Mail? By default all filters are global and you can narrow the filter scope by adding extra parameters. So the extra parameters could specify the target folder or account. With this model, filters would automatically be transferable from one account to another which is currently impossible to do. Come on people, I can't believe this thing has been around since 2000, what the heck is going on?
Blocks: 66425
+1 from me. There are approx 10 different bugs that are essentially duplicates of this one, this really wants some attention... Bug 227909 and Bug 285194 are similar to this bug and would be solved in the functionality described here were to be implemented.
I have a case where I'm taking the AND of two lists of 7 items each. If I wrote explicit filters, this would be 7x7=49, and the list is expanding. Right now I just apply the first 7, using a singe OR filter, to move the messages to a new folder, then I apply the second OR filter to that file. The rules are easy to manage this way. I can do this all automatically by setting up a dummy account for the intermediate folder, but it'd be cleaner if I could just manage this with files.
Flags: blocking-thunderbird3?
QA Contact: filters
Product: Core → MailNews Core
No longer blocks: 257415
I don't think we'd block on this.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
+1 Here is another scenario where per-folder filters would be useful: When connecting to an IMAP server, I want to be able to move all mail in my IMAP account's Sent folder to the Local Folder's Sent folder automatically. As it stands currently, I have to manually run a filter to achieve this when my IMAP account's Sent folder gets too large. :o(
(In reply to comment #39) > > When connecting to an IMAP server, I want to be able to move all mail in my > IMAP account's Sent folder to the Local Folder's Sent folder automatically. In TB3, we've added two features that should provide the capability to support this kind of request, at least though an extension: 1) You can now request that filters be applied on Imap folders other than the inbox. 2) With the new custom search terms, an extension could add a search term for a filter that is some property of the email's folder, such as the name or type. This is backend-only capability, so you need an extension to actually do these things. But such control will be possible from my FiltaQuilla extension, once I upgrade it to support these new capabilities. The existing version on Mozilla's AMO does not yet, but hopefully I will be able to upgrade it soon. There is one possible gotcha. Filters only work on new messages, as otherwise the same filter would be applied repeatedly. I believe that when TB adds an item to the Sent folder, it marks it as Read, which means it would not be processed by a filter even with the changes I have discussed. Perhaps we need to investigate ways around this issue.
Blocks: 227909
When a message gets sent, TB does mark it as read in the Sent folder. However, if you check "Return Receipt" in the compose window and have those set to go to your Sent folder, it shows up as unread. (And I assume you could use a filter to redirect other kinds of incoming mail to Sent and it would show as unread.)
I am using 3 Gmail accounts with Imap. I will give an example of what I want: some spams (in Spam folder) are marked with pretented sender Foo; if Foo is friend in my adress book, i want to move this mail to Spam/friends; other wise, don't touch it. This aims to regroup at one place spams that "may" be false positive. Messages left in spam folder have 0 chance to be false positive. When a friend tells me "havn't you receive my mail ?", i won't look in Spam, but Spam/friends, saving time to search about certainly-non-friend messages. So, i _have_ set a rule "if sender is in adress book, move message to this folder" (and of course I unticked it). If the rule is global, all my Inbox would be move at once to ThatFolder. So, I have to run manualy the rule on the spam folder. This is a case, amongst other ones, where I want a rule to run only on ONE folder. I would not mind having to run it by cliking the filter button, but, I do mind having to enter Filters pannel, selecting the account, selecting the folder, cliking once on the rule, triple-checking of the selected folder is the right one (imagine the damage if I ever run this on Inbox !!! ) (because of regression bug 273240 ), and press "run the rule once". There are three more cases where I need similar behaviour, but they are way more difficult to explain with words. This other one may be not so hard: when i send an email using gmail webmail, or my mobile phone, a copy of the sent email is placed in the Sent folder. When I start TB, i want that all mails from this folder are moved to the local Sent folder. If I set a rule "move any mail to local/sent" ... it will start by removing all mails from Inbox, and merge received Imap mails with sent local one, what it is obviously not what I want: I need a per folder restriction. And exactly the same kind as for Spam above.
plop: Thanks for providing the use cases. At least your first case ("if Foo is friend in my adress book, i want to move this mail to Spam/friends") could be met with the current capabilities of FiltaQuilla. That is, you could define a custom search term of type "javascript" with the following (untested) text: message.folder.name == "(the folder name)" then add a standard address book search term. Then you would need to enable filtering of that folder using FiltaQuilla's "apply incoming filters" inherited property so that filters are applied to the GMail spam folder. For the other case, the Sent folder, FiltaQuilla is unlikely to work because I doubt that Thunderbird would recognize the sent messages as new messages that are subject to filtering. That's a whole nuther topic, but one that is closely related to the issues here. This is all very complex, I admit. The goal of FiltaQuilla was to push the envelope of what filters could do, but not necessarily to make it easy or accessible to the average user. I think that it is generally recognized that the filter interface is already too complex for most users, and that what is needed is some sort of shift in design to make it more accessible. That and other things (http://mesquilla.com/2010/04/12/what-filters-need/). I still think that the goals of most users could be met by a simple folder search term in the short run. I doubt if it makes sense for mail to follow the same system as newsgroups, where filters can be defined on folders as well as servers, as that adds too much additional complexity to all filter users without much (if any) additional benefit over a simple search term.
Another use case: I have several different active email accounts (some IMAP, some POP3). I want certain messages marked as "to-do" (e.g., transaction notices from banks, various other statements and notifications) -- regardless of which account they come to (I want to filter on sender, not sendee) -- and after I process them, they usually get deleted. If I don't do anything about them, they clutter up my main mailbox, which I would like to reserve for mail I actually WANT to read (e.g., from friends). Today (TB 3.0-3.1), I accomplish this via smart folders: I exclude those things from showing in inbox smartfolder, and I include them in a search-based "to-do" smartfolder. This works pretty well, but the exclude/include lists are getting pretty long -- the longer the list of things I want to put into the "to-do" folder, the more cumbersome it becomes to maintain both inbox and to-do smartfolders. I would prefer to have a global filter that applies to incoming mail on all selected mailboxes (similar to the way smartfolders select their targets), such that if email is coming from x@y.com (or has something in the subject, or whatever), I tag it "to-do;" I would have inbox NOT show items tagged "to-do" and have "to-do" smart folder show ONLY items tagged "to-do." That would make administration sooooo much easier. The interface already exists for filtering based on smartfolders. I just want to tie a particular action (e.g., "tag as ABC") to incoming mail that meets the criteria, regardless of the account. That's my $.02. - mdeck If filter were allo
mdeck: If I understand you correctly, I think that you are arguing for a global filter (bug 34973), not for per-folder filters as this bug requests. That bug is clearly in the category of "we would do it if we had the time", while this one is more "not sure the complexity justifies the value for most users".
I want this for categorizing bugmail. My use case: I send my bugmail to gmail, and use that as my primary interface for reading the mail. Most of my bugmail comes from watching qa contacts. I would like to have gmail filter it into appropriate categories -- for example, right now I have one label for JS engine bugs and one for JSD bugs, and I want only the watched mails to go into those. Everything else should stay in my inbox. Unfortunately, gmail's filtering does not support custom headers, so I can't properly do this. Instead, I use Thunderbird to do the fine-grained filtering, grabbing things out of the inbox and putting them into bugs-JS and bugs-JSD, or leaving them in the inbox if they were sent for some other reason (eg I'm cc'd, or it's my bug, or whatever.) However, thunderbird is not always running. It's on my laptop, which is sometimes asleep when I use another computer to get to my gmail account. As a result, I get deluged with bugmail that clutters up my inbox until I turn the laptop back on and hook it up to a network. So instead, I have gmail tag all bugmail as "bugs-unfiltered" and archive them (remove the inbox label). Now I want Thunderbird to filter only the bugs-unfiltered folder and categorize things. I'm doing this now, but I have to run the filter manually since it doesn't apply to bugs-unfiltered. I just installed FiltaQuilla to fix that problem, and it appears to be working. But this still isn't quite optimal. I have to tell FiltaQuilla to *not* filter things in other folders, mostly because it's a waste of time but if I did more with filtering, it might actually break things. I'd really like to be able to run a different set of filters depending on the mailbox. (I don't have any need yet for chaining, and like the safety of having a message only filtered once. Perhaps have an action "renominate for filtering" so that at least you have to be intentional about shooting yourself in the foot?) I'd like to see this as another part of the criteria for each filter. Or perhaps as a generalization, allow attaching arbitrary tags to folders and match folder tags in filter rules.
Let me respond about FiltaQuilla, though this is sort of OT, but not completely since a request to do a core change implies that the approach using an addon is inadequate. In FiltaQuilla, you could right now set up a custom js search term that checks the folder name, and then have that as the first item in the filter search. I would also like to add a standard FiltaQuilla search term for folder that would do the same thing without the custom js search term. Actually I'm surprised you have this problem at all, as normally IMAP will not filter folders other than the inbox, unless you enable those using the inherited folder property in FiltaQuilla. What I would expect is that only enabled folders would be filtered at all.
My solution, to both problems (Moz+Gmail lack of features): change thunderbird launcher by home made script that will call the renamed original launcher ... after doing a few tasks: - run fetchmail (that is Imap capable) to fetch particular things, and download particular emails to specific folder (folder to folder actions, accross accounts; TB can't do it) - run fetchmail to filter spams (in local TB directory) with specific adaptive and very complex rules TB does not even dream of: * if the subject of an email contains the Date field, then, this kind of spam is sent by a specific spammer, and this is never a false positive * move to a subfolder all spams that are sent from a known address; this requires my script to access TB address book, and re-filter spams, but move only messages from spam folder * if we find in the spam folder more than 6 emails with same subject, or 8 from same sender throught them out (i doubt a friend of mine would be unlucky to the point he would send me 8 emails consecutively, and all of them would be false positive) (and matching criteria is backup in some keyword list so that future emails matching this will be removed faster). - move Gmail/Sent messages to Local/Sent - compact folders from outside TB - remove a few msf files to force TB resync This script removes 95% of incoming spam. Plus obvious security measures: check of TB is running, care about locks ... Takes a few dozen seconds; but it does the job; and I do way more this way than Thunderbird will ever be able to do, even if we ever close this bug with a FIXED status ... Steve; a home made script can do any thing you need. TB alone never will. And a script can play with labels as much as you want. Stop whining, and write a script. http://fetchmail.berlios.de/fetchmail-man.html
(In reply to comment #49) > Steve; a home made script can do any thing you need. TB alone never will. And a > script can play with labels as much as you want. Yes, I used to play these games too, mainly with a huge set of procmail rules. I no longer do that. I now have more hours in my days, the birds have started chirping again, and those obnoxious creatures prowling around turned out to be my family, and I've discovered they can really be a lot of fun. I've also customized fetchmail to do some tricky stuff, even after it regurgitated all of my email and sent bounce messages to a thousand senders. No longer; see above. > Stop whining, and write a script. > http://fetchmail.berlios.de/fetchmail-man.html Stop destroying your life competing against the spammers. Let others do the thankless work. Or at any rate, keep only the relevant discussion in this bug.
Blocks: 456094
Whiteboard: [filter-mgmt]
Blocks: 378343
In my humble opinion, this should be core functionality. Here's a very simple use-case: I don't want to be notified when new SPAM arrives to my IMAP account. My mail server (Dovecot + Sieve) moves SPAM messages to the "Junk" folder automatically. (To be clear, this happens server-side.) When SPAM messages are downloaded to Thunderbird, via IMAP, they are already in the "Junk" folder. As such, the "Mark as Read" filter is never applied (because filters are applied automatically for the Inbox only). As a result, I have to run the "Mark as Read" filter manually all the time (or right-click on the SPAM folder and choose "Mark Folder Read"). The annoyance is considerable. Somebody wrote a plug-in to deal with this lack of functionality (the fact that filters cannot be applied automatically to any folder other than the Inbox), so, most of the hard work has already been done. One would hope that the author's code could be updated to work with the current version of Thunderbird. https://addons.mozilla.org/en-us/thunderbird/addon/filter-subfolders/ Perhaps FiltaQuilla (discussed throughout this thread) is capable of accommodating the use-case that I've outlined above; from comment 48: "...as normally IMAP will not filter folders other than the inbox, unless you enable those using the inherited folder property in FiltaQuilla. What I would expect is that only enabled folders would be filtered at all." If so, I'd be curious to see how this is done, as it is not obvious.
(In reply to ben from comment #52) > In my humble opinion, this should be core functionality. > > Here's a very simple use-case: > > I don't want to be notified when new SPAM arrives to my IMAP account. My > mail server (Dovecot + Sieve) moves SPAM messages to the "Junk" folder > automatically. (To be clear, this happens server-side.) When SPAM messages > are downloaded to Thunderbird, via IMAP, they are already in the "Junk" > folder. As such, the "Mark as Read" filter is never applied (because filters > are applied automatically for the Inbox only). As a result, I have to run > the "Mark as Read" filter manually all the time (or right-click on the SPAM > folder and choose "Mark Folder Read"). The annoyance is considerable. > if You use sieve, there is no need to deal with thunderbird rules... just verify if your sieve server has "imapflags" feature and set setflag "\\Seen"; in Junk rule.
Blocks: 811124
I also have, what in my opinion is a core use-case: I have an IMAP account with a 250MB storage limit. I never delete any emails unless they are spam. My IMAP folder structure is somewhat typical in that beneath the Inbox I have multiple folders segregating emails by person or vendor. I have set up identically-named folders under Local Folders. I currently must manually move old emails from IMAP/subfoldername to Local Folders/subfoldername whenever I approach my IMAP limit. I think in this case, a per-folder filter would apply. I am posting here because I opened my own bug report (#933795) and was promptly told this, or 378343 are equivalent bug reports. This one seems closer to mine than 378343, so I am posting here.
8 years old querry ... just forget it, and mark the bug WONFIX.
You may want to check out these 2 addons: https://addons.mozilla.org/sk/thunderbird/addon/filter-subfolders/ (see how to make TB actually run filters on all IMAP folders) https://addons.mozilla.org/sk/thunderbird/addon/filtaquilla/ (maybe the "Javascript" search term can be used to make a criteria based on folder name).
I don't want to run the same filter across all my folders, I want to assign specific filters per-folder the same way I can currently assign them per account. Is this really so hard to implement?
I agree with Carl. Neither of those two extensions allow you to filter per-folder. Assuming a filter that would move all emails >15 days in age from IMAP to Local, I don't see how an account-level filter can know to move the 16 day old email in IMAP/John to Local Folders/John, while at the same time moving the 16 day old email in IMAP/Joe to Local Folders/Joe. If you can tell me how to do this, for 36 separate IMAP folders, my problem would be solved. Currently I am doing it manually about once a week, or whenever I get a notification that my IMAP account is nearing its storage limit.
I don't know if this will help, but I have decided to look at the problem from another perspective. I have multiple imap and pop accounts and I want certain emails to be prioritised, some (junk e.g. I don't even want to have to go through) I use the saved search feature to set up various searches on what I do want to see : everything this year, excluding trash and junk ; another folder for business emails (query involves several email accounts and tags) then I used the QuickFolders extension to display each search as a tab and close the folders sidebar @Tim I think you are essentially looking at archiving which can be configured per account and you can specify the target folder: https://support.mozillamessaging.com/en-US/kb/archived-messages I realise you can't specify the number of days in the archiving, which is really the issue for you, besides not being able to automate it, however if you set up a saved search to show emails > 15 days old in all your IMAP accounts you could then easily manually archive those messages I think you can also try this (I haven't used it...but it's linked from the TB info about archiving so I assume it's safe) http://www.broobles.com/imapsize/
Carl and Tim: the question is not to measure how difficult it is, but if the team really want to do it. The team prefers spending time on customizing the interface, and polish the shining aspects and break working features ... over implementing what users are asking since years (3 features have gone away during my TB3 to TB17 migration) For those who really need per folder rules, it's very easy to do: mboxgrep ( http://www.mboxgrep.org/ which is packaged in all good distributions). It can not run in // of TB, or it will break many things; it must run when TB does not. To make things transparent to the user (me), I have set-up a wrapper: in my window manager settings, I have edited the .desktop for TB to not run the TB binary in /usr, but a script in ~. The scrip starts by checking if TB runs already (ps + [ -f .thunderbird/default/foo.bar/lock ] , runs my filters, and remove all folder index files (the .msf files) (for the folders I changed) (to force TB regen the indexes that would otherwise be wrong), and then launch TB. The duration of process depends on what you ask for; during the process I produce a pop-up with Xdialogs that is killed on TB start. I use it in conjunction with getmail. Some complex filtering may require to download messages, filter locally, then re-upload them. Filtering by date is difficult, because it must be done the manual way (an email is a raw text file - loops are your friends). Filtering per read status ... I can't find that feature in any of the two manpages. But there must be an alternative; there is always one. And I will need it soon anyway.
(In reply to plop from comment #60) > Carl and Tim: the question is not to measure how difficult it is, but if the > team really want to do it. The team prefers spending time on customizing the > interface, and polish the shining aspects and break working features ... > over implementing what users are asking since years (3 features have gone > away during my TB3 to TB17 migration) Clearly this bug isn't mature enough yet. Bug 34973 has been open since 2000 and still is unresolved. Even working patches for open issues take 2+ years to get reviewed, much less approved. After attempting to contribute to this project for the past dozen or so years, it seems to me the only way to actually make progress here is to fork the code base.
There is no real mechanism within Thunderbird to ever resolve questions like "Filters should be per-Folder, not per-Account" That is not really a bug in the traditional sense, it is a statement of preference. I suppose I could mark this bug "won't fix", but that would cut off discussion,and I think the discussion is useful. "if the team really want to do it": My personal preference would be that if this is done, it be done in an extension, as there are downsides to doing this in terms of making filters more difficult to manage. But I am usually in a minority when I say that. "... take 2+ years to get reviewed, much less approved. After attempting to contribute to this project for the past dozen or so years, it seems to me the only way to actually make progress here is to fork the code base." It is really hard to get reviews through these days, and almost impossible for big features changes. However, as both a reviewer and someone who sometimes attempts big changes, I find that I spend too much time doing reviews of changes that I think are marginal, and not enough time implementing big changes that I could probably push through and are important. I have no solution to that. IMHO this current bug is not particularly important because it only applies to manual filters (incoming messages only act on the inbox anyway), and manual filters are probably not widely used. If you really want a filter to act only on certain folders, the "Folder Name" search term in FiltaQuilla can usually accomplish that. Yes it is a pain to use, but per-folder manual filters are pretty much an expert thing anyway. So do you have use cases that cannot be accomplished through FiltaQuilla's folder name search term? Within the current program, and minimizing impact to existing users, the best way to accomplish the point of this bug would probably be through a new search term anyway that added a folder selection, which is essentially the approach that FiltaQuilla takes anyway.
The problem for me is, learning FiltaQuilla and hoping it actually accomplishes what I am trying is likely to take more time than just continuing to do what I do manually. It is not terribly time-consuming now that I have the procedures down, so I don't relish the thought of having to invest the time in "trying to find a workaround" that may or may not work after my efforts. Hence my queries here. Before filing my initial report and being redirected to this report, I thought there may be some "trick" to getting what I was looking for through the existing Filter system. If it's not on Mozilla's radar to add this functionality, then so be it. I'll continue doing it manually. If I was a programmer, I'd probably be making my own extension, rather than posting here, but I'm not. Thanks anyway. Thunderbird is a very good product and I do appreciate the efforts involved to make it what it is.
Tim: there is not much to learn to FiltaQuilla. You install it, and you have lots of new search terms and filter actions available using the standard UI (though you may have to enable the ones that you use). I suppose the pain is that you would have to add a "Filter name" exclusion to each filter that you did not want applied. Then you would be able to manually run Tools/Run Filters on folder ..." rather than having to select a filter. This would have been much more powerful in combination with periodic filters, because those would have applied automatically.
> IMHO this current bug is not particularly important because it only applies to manual filters (incoming messages > only act on the inbox anyway), and manual filters are probably not widely used. If you really want a filter to act > only on certain folders, the "Folder Name" search term in FiltaQuilla can usually accomplish that. Yes it is a pain > to use, but per-folder manual filters are pretty much an expert thing anyway. I'm not sure what you mean by manual here, I enter my filters manually but set them to run automatically. What I want is for the filters to kick in automatically when a message is moved into a folder. That way I can manage a cascade of filters that apply to subsets of the messages. My only choice now is to expand the rules into 2^N individual cases, which is worse than having to manually move the messages individually. > My personal preference would be that if this is done, it be done in an extension, as there are downsides to doing > this in terms of making filters more difficult to manage. But I am usually in a minority when I say that. I don't see why per-folder filters would be harder to manage. An account is just another kind of folder, so we'd use the same interface to associate filters to accounts and folders identically. Would the implementation really be that different?
Kent: How do you add a filter name exclusion? Apparently you were right about that being the pain ;) I don't see that as an option, and googling the expression didn't bring up anything noteworthy.
Tim: In FiltaQuilla, for each filter that should not run on a folder, you would add a search term "Folder Name "Isnt" "(MyPeriodicFolderName)" That is just like you setup any other filter. Carl: "What I want is for the filters to kick in automatically when a message is moved into a folder" That actually is a little different than "Filters should be per-Folder, not per-Account". Usually automatic filters only apply to the inbox, so allowing you to specify a filter for a subfolder will not allow that filter to run automatically. There is an exception for IMAP which can be enabled in FiltaQuilla. So you could actually accomplish that today for IMAP folders and FiltaQuilla, being aware that there is a significant risk of filter loops if you are not careful. Install FiltaQuilla, enable "Apply Incoming Filters" for the folders that you want acted on, and just make sure that the Move actions into that folder are excluded using the folder name search term to avoid filter loops. But there is a caution. Automatic filters also only apply to unread messages, so if you read the message on a phone, you will disable the filter for that message.
(In reply to Kent James (:rkent) from comment #67) > Carl: "What I want is for the filters to kick in automatically when a > message is moved into a folder" > > That actually is a little different than "Filters should be per-Folder, not > per-Account". Usually automatic filters only apply to the inbox, so allowing > you to specify a filter for a subfolder will not allow that filter to run > automatically. There is an exception for IMAP which can be enabled in > FiltaQuilla. So you could actually accomplish that today for IMAP folders > and FiltaQuilla, being aware that there is a significant risk of filter > loops if you are not careful. Install FiltaQuilla, enable "Apply Incoming > Filters" for the folders that you want acted on, and just make sure that the > Move actions into that folder are excluded using the folder name search term > to avoid filter loops. On POP3 this seems to be possible using the periodic filters you are developing. It will not be immediate, but when the filters are run on the timer, if they have a term "Folder is <the wanted folder>" then it will do what the reported wants.
Thanks, Kent. I seem to have come up with a system that is a little better than manually moving. First, I make sure all automated inbox filters are set to "Apply filter when Checking Mail". Then, I create a filter for each IMAP folder I want to move >14 day old emails to its Local Folders equivalent. I make sure these filters are set to "Apply filter when Manually Run". Filter Rules set up as so (using Sent Items as example): Filters for: IMAP Filter Name: Sent Items Apply Filter When: Manually Run Match ALL of the following: -Folder Name is Sent Items -Age in Days is greater than 14 Perform these actions: -Move Message to: Sent Items on Local Folders Then i just have to left-click the folder, then go to Tools->Run Filters on Folder, for each folder. Assuming 36 folders, that's 36 filters to create and 3 clicks per folder to run the filters. That's still 108 clicks, but it does cut out the date checking, highlighting, and right-click->Move To.
Now that I've accomplished this, it leads to my wish of having "Run Filters on Folder" in the right-click context menu. I suppose I'll see if such a request has been made yet. if you happen to know, I'd appreciate a reply. Tim
Tim ... in TB3 ... I used to have "toolbar buttons" which added icons and buttons to the top bars; it's one of the many add on I lost during the TB3 TB17 migration. One of the button was "run filters on this folder"; I also had "compact". With this button, we could save one click to run filters. It's one of the many features I have lost last month after 3 years using TB3 ... because I was forced to try to upgrade to a recent TB ... because Google stopped the support for a now deprecated calendar sheme; the upgrade was completely useless because if the latest version of Lightning is said to work fine with the new cal sheme, in fact, it makes TB segfault. So last month I have lost Google calendar ... and many features of TB3 that have been broken ... or removed in TB17. The more I upgrade, the more I loose. To mention a non-plugin feature, I used to switch the left pannel view a lot using the two small arrows; it was quick and simple; now the arrows are removed, and I have to use the longer "view" menu. It's as many clicks, but in TB3, it was 3 clicks at the same place; in TB17 it's 2 clicks plus moves and waiting: it requires more precision, and more arm moves: it's more complex. So even if FileQuitta could do what I need (what is not the case, since I also need to filter read messages), life is now more complex due to the loss of the "run filters" button. I also used a lot the "show source" button ... was very handy to check headers when I had doubts about pishing messages ... (feature is still in, but is now two clicks). I am tired of loosing features on each update. Upgrade from TB1.5 to TB2 already made me loose mnenhy. TB2 to TB3 made me loose "Mail Redirect": the bounce feature (that's NOT forward !!!) oh ... an other thing that just gone away: the possibility to fold the message header (make it two lines) GRAAAAAAAA
plop: The best I could do was the extension Folder Filters Button 1.3. I then squeezed it to the left of the File menu, directly above my IMAP folder tree. It eliminates 1 click and reduces the mouse travel slightly. Although it's not ideal, it's better than what it was and for that I am grateful.

(In reply to Tim from comment #69)

Thanks, Kent. I seem to have come up with a system that is a little better
than manually moving. First, I make sure all automated inbox filters are
set to "Apply filter when Checking Mail". Then, I create a filter for each
IMAP folder I want to move >14 day old emails to its Local Folders
equivalent. I make sure these filters are set to "Apply filter when
Manually Run". Filter Rules set up as so (using Sent Items as example):
Filters for: IMAP
Filter Name: Sent Items
Apply Filter When: Manually Run
Match ALL of the following:
-Folder Name is Sent Items
-Age in Days is greater than 14
Perform these actions:
-Move Message to: Sent Items on Local Folders

Then i just have to left-click the folder, then go to Tools->Run Filters on
Folder, for each folder. Assuming 36 folders, that's 36 filters to create
and 3 clicks per folder to run the filters. That's still 108 clicks, but it
does cut out the date checking, highlighting, and right-click->Move To.

Further optimization of this method:

The following workflow allows one to cut down on the amount of clicks needed to manually run filters on folders outside of the inbox. 4 clicks are needed per "search folder" instead of 3, but since search folders can search within multiple folders, dozens and hundreds of clicks can be saved in certain use-cases:

  1. Use "Save as search folder" in the "Search messages..." CTRL + SHIFT + F dialogue
    • Choose the folder(s) to search.
    • Choose conditions you want to have applied to these folders. (e.g: Age in days is greater than 14)
    • Additional info: The search must apply to at least one folder. The great thing about "save as search folder": Folders from multiple accounts can be selected and searched! It allows to search (and thereby to use filters on the messages that were found!) across your whole Thunderbird Profile without having to create filters that copy/forward e-mails to inboxes of dummy accounts.
  2. Click on your search folder
  3. Select all messages (e.g. CTRL + A)
  4. Click on Tools in the menubar.
  5. Click on Run filters on selected messages

In short: The workflow described in comment #69 can be improved by first collecting (= search) all sent messages across multiple accounts in the search folder, then copy/move/forward/labeling them (via manually triggering the filter on the "search folder") to the inbox of an e-mail account or the local inbox. There, another (automatic!) filter could be triggered (e.g. Match ALL the following: "From countains youre-mailadress", "label is sent") and split them again by copying/moving these filters into separate sub-folders.

Blocks: 1625265
Severity: normal → S3
Duplicate of this bug: 1837039
Duplicate of this bug: 1713936
Summary: Filters should be per-Folder, not per-Account → Filters should be per-Folder, not per-Account - Filter on non-Inbox folders
You need to log in before you can comment on or make changes to this bug.