235354 - message filter does not assign labels

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Matt]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

When I assign a message filter, flagging and setting priority and everything BUT
labeling work. That is, the 'labeling' occurs correctly in the Filter Log, but
it just doesn't actually label the messages.

Reproducible: Always
Steps to Reproduce:
1. Create a message filter
2. Make it label as anything (work, important, personal, ...)
3. Also make it flag the message
4. Click Run Now

Actual Results:  
The correct messages are flagged, but not labeled.

Expected Results:  
The correct messages should be flagged AND labeled.

Comment 1

[Matt]

Okay, new information. It only acts this way when running the rule on already
existing mail.  It actually works correctly for newly recieved mail.

Comment 2

[Stephan Weller]

Happens with me too under Linux. So I assume it's OS-independent

Comment 3

[u97006]

Also happens for me on Mac OS X!

Comment 4

[Aaron Solochek]

Happens for me as well in linux using version 0.8 (20041008) (but I have noticed
this bug for a while).

I have an imap account, and use thunderbird both at work and at home (on
different machines) to check it.  New messages get correctly labelled, but, as
was pointed out, existing messages to not.  In my situation that means that all
mail received during the day (when my home thunderbird is shutdown) are only
correctly labelled on my work machine.  The opposite is also true, as you
probably guessed.

Comment 5

[RDL]

Same problem for me on Windows XP but not IMAP.
My filter was also (successfully) moving hits to another folder so I suspected a
timing/sequencing problem but when I tried without the moves I had exactly the
same problem.
A filter like "when 'to' contains 'fred' then label as 'output'" stops labeling
after the first eligible mail has been done. I.E. it does the first ok but only
the first. It was actually working OK for the first day or two I had the filter
but stopped afer that. I managed to get it back by rolling back the profile,
replacing the target folder and re-doing the filter. It stopped again after a
few hours so I gave up.

However with "when 'age in days' < 36525 then label as 'output'" works fine and
runs through the entire target folder labelling everything as required.

I am only working within 'Local Folders' for my mail management but that comes
in through up to five accounts. The 'output filter' in question is run manually
on 'sent' within 'Local Folders' and if set to also move was to various folders
 under 'sent' in ditto.

TB is set up standard on C: but my Local Folders is held in my own 'mail' folder
on a separate partition, D:. The filters in question are as standard in that
folder. My input filters are as required under their accounts and work fine.
Yhey also use labelling, based exactly similarly but on 'sender' not 'to'. They
work fine and label correctly running automatically under the TB client.

Comment 6

[RDL]

Please see this ThunderBird Bugs forum topic on MozillaZine - RDL

Comment 7

[mdanielsco]

Happens for me, too.  Using 1.0RC on Linux with an Exchange IMAP server.

Comment 8

[RDL]

Please, why is this bug being ignored? It must be trivial for someone inside the
code to fix. It has a highly visible effect for something that should work
without sweat and it's very frustrating. No-one has responded to it or noted any
reaction whatever. Please look at that forum topic if you don't believe people
see it.

As for "leave as unconfirmed" *!*?**! as Tas would say. Everyone on that topic
had it confirmed for them without even looking for it!

Please look at it seriously instead of ignoring it!

RDL

Comment 9

[RDL]

Perhaps it has no priority because no-one is allowed to vote for it?? It seems
to be lying here in a dark corner because no-one apparently realises the use
wanted for this facility and why we would really like the bug fixed - please.
and as I go to press "commit" I see that stubborn little indicator saying "Leave
as unconfirmed". Why, have we been bad? RDL

Comment 10

[David :Bienvenu]

confirming, but no promises about when I can get to it.

Comment 11

[David :Bienvenu]

this works fine for local mail - I'll try it for imap.

Comment 12

[David :Bienvenu]

works for me with imap as well.

Comment 13

[RDL]

Are these possible causal Possible Factors; Working only in Local Folders;
Having Local Folders on different partition (D:) from the profile (C:); changing
the name of labels (4="input" 5="output").... Any bells ringing, sirens wailing?
Is there any kind of trace switch we can turn on to produce useful information?
The filter log doesn't help as others have confirmed that it shows the label
action as logged but no label name associated. When you ran and it worked did
the log show label names? If so, why don't they get logged on ours?

What is the difference between the code executed when control is on the input
side under the account incoming mail handler (automatic, which works) and the
output side under solicited folder handling logic (manual which doesn't)? I have
a suspicion that on the input side it only handles one at a time in a complete
loop. Since on the output side it always does the first and only the first hit
item in the folder correctly but after that it fails I wonder if something is
incorrectly left set/unset from the first item handled in the batch and it then
runs through all the rest using that incorrect setting. On the input side the
start of a new receive/process routine for each incoming item could lead to that
setting being correctly re-initialised for every item. Any chance? RDL.

I've tried uninstalling all extensions but that doesn't cure. Most of the
extensions were added after the problem first appeared anyway.It doesn't help
that there is no such thing as a clean uninstall does it? For that reason here
is a list of my current extensions. Just in case one of them sounds a familiar note.

Last updated: Fri, 17 Dec 2004 03:41:02 GMT

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041103 Thunderbird/0.9 Mnenhy/0.7

*** Extensions (22):
AboutConfig 0.4
Buttons! 0.4.9
ChromEdit 0.1.1.1
Contacts Sidebar 0.4 
EMbuttons 0.3.3 
Fix Tb Titlebar Extension 0.4.4
Grippies 0.1+ 
InfoLister 0.7.5
MessageID-Finder 1.9.9
Mnenhy 0.7
More Button Plus 0.31
No New Window on Double Click 0.1.0
Outbox 0.21
Preferential 0.6.1a
QuickNote 0.6
Quicktext 0.1.1
Quote Colors 0.2.5
QuoteCollapse 0.4
Shift-Delete Controller 0.2c
Show Old Extensions 0.1.7
Tb AutoSave Extension 0.0.7
TB Reset Quote Header Extension 0.2.8

*** Themes (1):
Thunderbird (default) 2.0

The only things I've change with surgery are in user.js as follows

user_pref("mail.compose.max_recycled_windows", 0);
user_pref("mail.ui.display.dateformat.today", 2);

I've tried deleting all mail index files and 'panacea' but apart from creating
chaos in my label colouring (lots of 'important' appearing) and re-marking all
my mail as unknown junk status (neither surprising with indexes blitzed) no cure
- fresh manual filtering just moved without labeling.

Comment 14

[RDL]

I have some news which may be useful for those on Windows XP. On 26 Dec 2004 I
totally uninstalled TB 0.9 (replied 'yes'' when it asked if it should delete
folders with remaining files). I did not start a new profile (too many accounts
etc to want that effort 'just in case') I didn't uninstall my extensions first.
(wanted to, 'just in case' but when the last batch went they took my file and
edit menus with them so I chickened out and restored the profile with a copy)

I then installed TB 1.0 using the exe installer. It went OK, picked up my old
profile and only left me to upgrade about four extensions for which I had
already downloaded the xpi's.


NOW THE BEST BIT! Since then (I gave it a week before shouting) labelling has
worked as desired when running filters manually on Local Folders!

I know that mdanielsco (Forum) found it still existed in 1.0RC and Kalimero
(Forum) found same in 1.0 full release. Is this because they may be using IMAP
(instead of my POP3) or could be on different platforms (instead of my Win XP
SP2) or could the change be because I did a full software uninstall (but keeping
my profile) before installing TB 1.0?

It could be worth people trying a clean s/w uninstall and re-install if they
still have the problem even on 1.0.

I have posted this info on the forum. There it may help someone escape the
problem and here it might help someone lock onto any remaining problem. RDL

Comment 15

[Jeongkyu Kim]

Attachment: patch for fixing 'label' filter action

In thunderbird, filter implementation varies on type of folders(local or imap)
and type of messages(new or existing). And this bug only happens in assigning
label for existing messages on imap folder ( see comment #4 in bug 271930 ).

nsresult nsMsgFilterAfterTheFact::ApplyFilter()
{
...
   case nsMsgFilterAction::Label:
     {
       nsMsgLabelValue filterLabel;
       filterAction->GetLabel(&filterLabel);
       m_curFolder->SetLabelForMessages(m_searchHitHdrs, filterLabel);
     }
     break;
...
}

If you take a look at the source code, you will find that thunderbird simply
calls nsImapMailFolder::SetLabelForMessages() in the case. However, the method
stores label flag on server but does not assign label on message db. I created
patch to solve this by referring to MarkMessagesFlagged() method.

Comment 16

[Zer0halo]

I'd like to confirm that I am experiencing the same problem with TB 1.0 on
Linux. Message filter that labels existing messages works in my POP3 account
Inbox, but not in my IMAP account Inbox. (I have separate inboxes for my POP3
and IMAP accounts.) 

Comment 17

[Duncan Miller]

I have noted this problem for some time and assumed that it would have been
resolved by now, so I am keen to know when it is. Thanks

Comment 18

[Jeongkyu Kim]

Comment on attachment 170316 [details] [diff] [review]
patch for fixing 'label' filter action

seeking r?

Comment 19

[David :Bienvenu]

Comment on attachment 170316 [details] [diff] [review]
patch for fixing 'label' filter action

looks good, thx.

Comment 20

[David :Bienvenu]

fix checked in, thx much, Jeongkyu.

Comment 21

[Mike Cowperthwaite]

A little late, but moving to Core in case of later searches.

Comment 22

[Mike Cowperthwaite]

*** Bug 237378 has been marked as a duplicate of this bug. ***