41850 - Filter UI: Case where new filter isn't added to list (ever)

Status: VERIFIED FIXED

(MailNews Core :: Filters, defect, P3)

Description

[laurel]

Using:
2000-06-07-08 m17 commercial build, NT 4.0 and mac OS 9.0
2000-06-07-10 m17 commercial build linux rh6.0

A newly added filter is not retained when following the steps below.  The filter
is not added to the filter list, does not appear after OK from main dialog and
reopening dialog, doesn't appear in list even after exit and restart.

1.  From mail window, launch message filters ui (Edit|Message Filters). In the
main dialog, click New to launch filter rules dialog.
2.  In the new filter rules dialog, type a filter name, select AND/OR, fill in a
simple subject contains <text> criteria line.
3.  In the Action section, leave the action set to Move To Folder and leave its
corresponding value dropdown (where you'd normally select a destination folder)
blank.  Click OK to confirm out of the filter rules dialog.
4.  An alert displays telling you to select a destination folder. OK the alert
and then select a destination folder (on the same server). OK from the filter
rules dialog.
5.  Notice the new filter doesn't appear in the main dialog's filter listing.
Click OK from the main dialog and go back in. Filter still doesn't appear in the
list. Close the dialog (by OK, Cancel or close box).
6.  Exit Netscape, relaunch and go to message filters.  Filter doesn't appear.

Result:  Filter is not saved, even after exit/relaunch. Not displayed in ui, not
saved in rules.dat.

Comment 1

[Alec Flett]

fixed. problem was just broken logic when we popped up an alert.

Comment 2

[laurel]

Using jun08 commercial build this is not fully fixed, but has changed.
The filter does indeed wind up displayed in the main dialog's filter list, but
the filter gets saved without any of the criteria.  If you edit the filter,
you'll see the filter rules dialog has no criteria lines (even a default blank
one!) and the filter is written to the rules.dat similarly without criteria.

Comment 3

[Alec Flett]

how odd, this was working for me, I swear.

Comment 4

[Alec Flett]

I figured out what's going on. It's a wierd interaction between the search terms
in the order in which the filter gets created & saved. I've fixed up this code
to be much more robust.

nominate for nsbeta2 - without this fix, if the user forgets to choose a target
folder, the user thinks he/she has entered a bunch of search terms when in fact
everything is lost.

Comment 5

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 6

[Alec Flett]

fix is in.

Comment 7

[laurel]

Seems OK using jun18 m17 commercial builds, linux rh6.0, NT 4.0 and mac OS 9.0

Tried several scenarios, all ok. If I find some outside case which doesn't work
I'll log a separate bug.