Closed Bug 369745 Opened 13 years ago Closed 11 years ago
mail filters which apply tags (keywords) and move messages sometimes lose tags
There are reports on the forums that mail filters that apply tag(s) and then move the message result in messages without the tag(s) applied. See the forum discussion at http://forums.mozillazine.org/viewtopic.php?p=2735512#2735512
Just to keep track: this was spun off from bug 366508. xref bug 254589: IMAP loses Tags (used to lose Labels), and Junk Status, and filter-added Priority. However, that thread is talking about POP mail. I just tested POP, and whether I tag first and then move, or move first and then tag, the messages in the (local) destination folder are tagged as expected. TB 2b2-0210, Win2K.
Summary: mail filters which apply keywords and move messages sometimes lose keywords → mail filters which apply tags (keywords) and move messages sometimes lose tags
I'm not sure what's going on, but I'm seeing this working for IMAP now. This is with a fastmail.fm IMAP account. The messages I sent to test appeared in the destination folder without coloring. I later happened to return to the folder and discovered the messages were colored. I just sent a new pair of messages to trigger the filters (one tag-then-move, the other move-then-tag), and they showed up colored right away.
Had the same problem in even the very newest builds (tag not applied by filter upon download, only upon manually running the filter) and found a 100% repeatable solution: turn off "allow antivirus programs to filter individual incoming messages."
re: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070309 Firefox/18.104.22.168. Filters won't add tag colors when moving mail to folders. The same filter works okay when run manually.
If possible, this should probably be merged with: https://bugzilla.mozilla.org/show_bug.cgi?id=377541 I don't know how to do that (or if I am allowed to) but these describe the same issue (the other bug report was one I started for clarity, which in retrospect may not have been the best idea). Actually, there are probably two or three like this floating around that could be consolidated, and that one (377541) has the cleanest description I could come up with.
I have the same problem in TB 2.0 RC 1, POP 3: A filter shall move the received mail to a particular folder and tag it. The move is done, but the mail is not tagged. If I do it manually, both actions work all right. I have done several tests with new filters, but the results could not always be reproduced. Sometimes the filter action was even different when I closed TB and restarted it. In one case with automatic filtering, I had: 1) move 2) tag: only the move was done. I added a third action to the same filter (star) and the mail was moved and tagged, but not starred. Since this all seems to happen quite randomly, I am not sure if my findings are very helpful
TB version 22.214.171.124 (20070326), POP3 I have had the same problem on new mail, and (seemingly) solved it by reapplying the same tag in the filter, before moving the tag. Have not tried to turn off "allow antivirus programs to filter individual incoming messages.", although I'm sure this'll work.
Yes it's the same bug found here : https://bugzilla.mozilla.org/show_bug.cgi?id=377541 It's connected to the "allow antivirus clients to quarantine individual messages" option. And the filter is not applied to the incoming mail, but to another mail in the inbox.
I have Thunderbird 2.0 and AIM mail. None of my tags 'stick' - when downloaded, nothing happens, and when filter run manually tags appear [color coding of mail] but then disappear. The 'allow anti-virus client . . .' option is NOT selected.
Anyone see this still, with tb126.96.36.199 or newer?
Assignee: mscott → nobody
From Magnus Melin 2008-01-18 comment #11 > Anyone see this still, with tb188.8.131.52 or newer? no responses. I'm guessing Magnus was thinking "dupe to bug 355537". doing so
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 355537
You need to log in before you can comment on or make changes to this bug.