Closed Bug 47137 Opened 24 years ago Closed 16 years ago

Bad behavior editing filters with unimplemented criteria.

Categories

(MailNews Core :: Filters, defect, P2)

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: laurel, Unassigned)

References

Details

Using july31 m17 commercial build

Related bugs:  bug 40380 (Date criteria), bug 40500 (Age in Days)

I'm logging this bug to document this behavior in light of recent decisions to
future unimplemented filter criteria and leave them sitting as choices in the
criteria dropdown.  Note: we haven't (yet) futured fixing the Date choice, but
Age in Days has been futured. 

If you've migrated a filter from 4.x which specifies unimplemented/invalid
criteria for 6.0, you cannot edit it to use a different criteria. You must
create a new filter instead.

If you create a new filter in 6.0 using an unimplemented criteria type, when you 
go to edit the filter, the filter rules shows no criteria line at all. You must
click More to get the default line.  

1.  In 4.x set up a simple one line date filter for POP or IMAP.
    Example criteria: date, Is , <choose a date>
2.  Exit 4.x and migrate the profile to 6.0
3.  In 6.0 go to mail window, Edit|Message Filters. Select the migrated date
filter and click Edit.
4.  (Note the criteria is messed up in the ui, that was mentioned in bug 40380)
5.  Change the criteria type to Subject or Sender, Contains, <type some text>.
    Confirm OK from the filter rules dialog.
6.  Select the filter and click Edit.  Notice the filter ui has returned to its
original invalid state:  Date,Contains,<blank>.

Result:  Edit behavior is awful on filters ever having unimplemented/invalid
criteria choices.  Changes are not kept, criteria may show a mixed up operators
choice list, or edit rules dialog may show no criteria lines at all. 

In each case, the effective workaround is to create a brand new filter. This may

Expected:  Even though we don't support certain criteria choices, it should not
affect the ui's ability to edit a filter. I should be able to change criteria to
valid choices and have the changes saved in ui and to file.

Note: there are many combinations here, many giving different but all weird
results.
Sorry I committed this before I finished composing it and editing it.

This problem may be more intrusive if a user composed a more compound filter. 
In the more compound filters, any criteria line after the unimplemented one(s)
gets deleted from the ui.  In most cases, the rules.dat is primarily okay --
this is dependent on what invalid criteria you choose.

In the compound filter situation, a user would either have to recreate the
compound filter or know to hand edit/copy the rules.dat.
Keywords: nsbeta3
QA Contact: lchiang → laurel
I'm just asking in advance of discussion. Which is the easiest thing to do:

1. Remove the criteria that doesn't work.
2. Implement the critera that doesn't work.
3. Fix this bug?

the last choice being of course, to just let this bug exist and not do anything 
to unimplemented criteria.
Keywords: mail4
easiest is to remove the unimplemented stuff,
but SOME of them will be fixed with some of the other bugs I've been working on 
(landing probably early next week)
I'd kind of like to hold off on bugs like this until that landing, and then 
evaluate from there.
ok, we'll mark [b3 need info] to keep this on our radar and wait until Alec 
lands most of his filters stuff he mentions above.
Whiteboard: [b3 need info]
alec, have you had a chance to land this?
Also, do you have an ETA for this?  
yeah, I'm taking a stick to the filter front end hope to land soon
Status: NEW → ASSIGNED
per mail triage, remove unimplemented filter criteria if this cannot be fixed.  
This is like a circle since those bugs to remove unimplemented filter criteria 
was marked future which lead to this bug :-)

for now, I'll mark + per mail triage, mail1, P1.
Keywords: mail4mail1
Priority: P3 → P1
Whiteboard: [b3 need info] → [nsbeta3+]
Target Milestone: --- → M18
to pdt: we made this a P1 due to the confusion of using filters which contain 
criteria which we decided not to implement (as per other bug reports).  To the 
user, it would appear to be a loss of functionality (ie. filters the user has 
are not working)
PDT thinks this is a P2, marking as such and leaving [PDTP2] breadcrumb
Priority: P1 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]
nsbeta3-
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2][cut 9/11]
Target Milestone: M18 → Future
removing the mail1 keyword
Keywords: mail1
Removing the mail1 keyword.
reassigning my filter bugs to gayatrib..
Assignee: alecf → gayatrib
Status: ASSIGNED → NEW
Depends on: 77232
No longer depends on: 77232
Blocks: 77248
reassigning to naving
Assignee: gayatrib → naving
bug 40380 (date criteria) and bug 40500 (age in days) have recently been fixed.

I can't test profile migration, however editing filters that use these criteria
WFM 2001071806 Linux.
There are no search criteria unimplemented still visible in UI (I emailed QA
about this, and have been using search a lot recently). And since we will never
make one visible which doesn't work (would be totally illogical to do so
anyway), I believe this bug can be safely closed.

Do you agree laurel?
If you say so,hwaara. I'm not on the trunk. And you mention search, which wasn't
the only problem -- filters were a problem and migration was, too. So, do what
you want, I'm not going to verify it until I get to the trunk anyway.
Ok, I will do some more testing first...
Hmm.. I think current filters/search is fine. But I don't know about migrating
filters with actions/criteria that Mozilla doesn't have implemented...

I will leave this open, in hope that someone can try migrating and see if it works.
Removing adequated PDT grafitti.
Whiteboard: [nsbeta3-][PDTP2][cut 9/11]
mass re-assign.
Assignee: naving → sspitzer
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
dmose, a wontfix?  No bugs have been made dependent/complaining of bad behavior as a result.  However, I'm not in a position to judge whether this is an issue only when migrating from netscape 4.x. 
Severity: normal → minor
QA Contact: laurel → filters
->WFM since there are no reported problems - and ns4.x migration has been removed on trunk already.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.