Bad behavior editing filters with unimplemented criteria.

RESOLVED WORKSFORME

Status

MailNews Core
Filters
P2
minor
RESOLVED WORKSFORME
18 years ago
10 years ago

People

(Reporter: laurel, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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.
(Reporter)

Updated

18 years ago
Keywords: nsbeta3
QA Contact: lchiang → laurel

Comment 2

18 years ago
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

Comment 3

18 years ago
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.

Comment 4

18 years ago
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]

Comment 5

18 years ago
alec, have you had a chance to land this?

Comment 6

18 years ago
Also, do you have an ETA for this?  

Comment 7

18 years ago
yeah, I'm taking a stick to the filter front end hope to land soon
Status: NEW → ASSIGNED

Comment 8

18 years ago
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

Comment 9

18 years ago
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)

Comment 10

18 years ago
PDT thinks this is a P2, marking as such and leaving [PDTP2] breadcrumb
Priority: P1 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]

Comment 11

18 years ago
nsbeta3-
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2][cut 9/11]

Updated

18 years ago
Target Milestone: M18 → Future

Comment 12

18 years ago
removing the mail1 keyword
Keywords: mail1

Comment 13

18 years ago
Removing the mail1 keyword.

Comment 14

18 years ago
reassigning my filter bugs to gayatrib..
Assignee: alecf → gayatrib
Status: ASSIGNED → NEW
(Reporter)

Updated

17 years ago
Depends on: 77232
(Reporter)

Updated

17 years ago
No longer depends on: 77232
(Reporter)

Updated

17 years ago
Blocks: 77248

Comment 15

17 years ago
reassigning to naving
Assignee: gayatrib → naving

Comment 16

17 years ago
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.

Comment 17

17 years ago
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?
(Reporter)

Comment 18

17 years ago
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.

Comment 19

17 years ago
Ok, I will do some more testing first...

Comment 20

17 years ago
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.

Comment 21

17 years ago
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

Comment 24

11 years ago
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

Comment 25

11 years ago
->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
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.