41770 - new Filters not firing

Status: VERIFIED FIXED

(MailNews Core :: Filters, defect, P1)

Description

[Phil Peterson]

Using 2000-06-04-20 commercial build on NT

1. Bring up message filters dialog. It's empty
2. Create new AND filter: Sender contains bugzilla-daemon moves to "Bug Reports" 
IMAP folder
3. Quit app and restart
4. Get mail. Bugzilla mail hits Inbox rather than Bug Reports as expected

Comment 1

[Phil Peterson]

Attachment: My rules.dat file

Comment 2

[laurel]

Same for POP.
Tried actions MoveToFolder (to folder name without spaces), Delete, Mark read. 
All no go.

I did notice the "type" field in the rules.dat file get quite long
sometimes..."190343856"

Comment 3

[laurel]

Oh, just to clarify... migrated filters using similar criteria and actions are
firing.

Comment 4

[laurel]

After a few other tries of adding new filters through 6.0 ui, I see that there
often are no criteria or action lines written to file.

Comment 5

[laurel]

Using jun7 m17 builds I never see any criteria or action or action value lines
being added. IMAP or POP, any criteria, any action, any value.

Comment 6

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 7

[Alec Flett]

ok, I discovered the first interesting thing - if any error comes up when you 
hit ok, it doesn't save that filter (the larger problem of the specific case 
laurel saw).. I've got that fixed.

the other problem seems to be that it's not saving the filter terms, and I have 
a theory about that, since the new filter is being written as type="-842150451" 
instead of type="1"

Comment 8

[Alec Flett]

yep, turns out it was just an uninitialize variable... 
fix is in.

Comment 9

[laurel]

This is OK using:
2000-06-08-11 m17 commercial build linux rh6.0
2000-06-08-08 m17 commercial build NT 4.0
2000-06-08-08 m17 commercial mac OS 9.0



New filters added through seamonkey ui are generally firing for IMAP and POP
(having some POP problems after initial firing).  Specific problems will be
logged separately.