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.
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.
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: mail4 → mail1
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]
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2][cut 9/11]
removing the mail1 keyword
Removing the mail1 keyword.
reassigning my filter bugs to gayatrib..
Assignee: alecf → gayatrib
Status: ASSIGNED → NEW
reassigning to naving
Assignee: gayatrib → naving
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]
Assignee: naving → sspitzer
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
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.