Closed
Bug 183158
Opened 22 years ago
Closed 21 years ago
filters/views spontaneously change themselves (Status criteria reset)
Categories
(MailNews Core :: Filters, defect)
MailNews Core
Filters
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.4final
People
(Reporter: dan, Assigned: Bienvenu)
References
(Blocks 1 open bug)
Details
(Whiteboard: [adt3])
Attachments
(2 files, 1 obsolete file)
1.38 KB,
patch
|
sspitzer
:
review+
sspitzer
:
superreview+
sspitzer
:
approval1.4+
|
Details | Diff | Splinter Review |
916 bytes,
patch
|
sspitzer
:
review+
sspitzer
:
superreview+
sspitzer
:
approval1.4+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021122 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021122 I create filters to label mail in color by status. For example, mail of status "replied" get a filter to label it blue. Later, I see that the filter has changed, by itself, to label "read" mail as blue instead of "replied" mail. Reproducible: Always Steps to Reproduce: 1. create filter to label replied mail as blue 2. work on other things 3. come back and see that the filter has changed to label read mail as blue Actual Results: filter labels read mail as blue Expected Results: filter should label replied mail as blue theme happens to be classic
I believe there's existing report -- status filters have never worked. They weren't applicable until we (recently) implemented manual/after-the-fact filtering. Since filters worked only on New/Unread messages previously, there was no great reason to apply filter on status. Now that we have manual filtering in place, we have to revisit the state of filtering on status. Will look for existing report(s).
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: nbaca → laurel
Summary: filters spontaneously change themselves → filters spontaneously change themselves (Status criteria reset)
*** Bug 186212 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
OS: Windows 2000 → All
Hardware: PC → All
Summary: filters spontaneously change themselves (Status criteria reset) → filters/views spontaneously change themselves (Status criteria reset)
*** Bug 188166 has been marked as a duplicate of this bug. ***
*** Bug 193119 has been marked as a duplicate of this bug. ***
*** Bug 194535 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
There should be a way for finding this Bug searching for "mailviews". I would help solving this if anyone tells me where to search, because I'm not to familiar with the Moz-Source, but quite interested is solving this.
Comment 9•22 years ago
|
||
Might it be, that this bug has to do with bug #189890?? I'm afraid it'l take quite a while for me to get used to the code.
Comment 10•21 years ago
|
||
*** Bug 195286 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
Email filtering is, in the last few days, less than useless. Each time I've re-installed a current version, on 2003031408, the filters are somehow altered by the new build and several of them are taken out of service. That's not too bad considering filtering hasn't worked at all for about 3 days. I finally had to remove file msgFilesRules.dat, which in my case is a good sized file, to filter all my legitimate mailboxes plus many filters to send spam to the trash folder. With the filter file I have been using for several months in its proper place Mozilla would lockup just trying to download new email. hrs Harvey R. Savage
Reporter | ||
Comment 12•21 years ago
|
||
Just wondering whether someone is working on fixing this one, so I can stick with Mozilla and not install something else because I need mail filtering that works. Thanks. I greatly appreciate all the volunteer effort that goes into Mozilla, which is actually very stunning.
Assignee | ||
Comment 14•21 years ago
|
||
I looked at this, and was not able to reproduce the problem. Is it still occurring with 1.4b/final builds?
Reporter | ||
Comment 15•21 years ago
|
||
I do not use 1.4b. I use 1.3.1 because I am in a "production" environment. It certainly happens in 1.3.1 Since there is no indication it has been fixed, I assume 1.4 still has it.
Assignee | ||
Comment 16•21 years ago
|
||
well, I was not able to reproduce any problem like this in 1.4b - my status filter hasn't changed in several days. This is either an indication that it has been fixed, or that this problem isn't 100% reproducible.
Comment 17•21 years ago
|
||
I'm still seeing it in 1.4b. My way to reproduce: 1. Create filter using status = read. 2. Quit Mozilla 3. Start Mozilla and inspect the filter you created. It now uses status = replied instead of status = read. This is on MacOS X. My filters only change when I quit Mozilla, and start it again, not while I keep it running.
Assignee | ||
Comment 18•21 years ago
|
||
ah, ok, now I see it, thx. It's very specific to "read", apparently. Shouldn't be hard to fix. I don't think it's going to account for the other strange behaviour described here, though.
Assignee | ||
Comment 20•21 years ago
|
||
Comment 21•21 years ago
|
||
Comment on attachment 123281 [details] [diff] [review] proposed fix r/sr/a=sspitzer very odd, we must never have tested this code.
Attachment #123281 -
Flags: superreview+
Attachment #123281 -
Flags: review+
Attachment #123281 -
Flags: approval1.4+
Comment 22•21 years ago
|
||
I'm guessing there are bugs logged by nbaca that will be fixed by this.
QA Contact: laurel → nbaca
Target Milestone: --- → mozilla1.4final
Assignee | ||
Comment 23•21 years ago
|
||
*** Bug 199464 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•21 years ago
|
||
the ui for picking a status switched new and forwarded, from what I can see.
Assignee | ||
Comment 25•21 years ago
|
||
not switched, just wrong. This seems to work.
Attachment #123300 -
Attachment is obsolete: true
Comment 26•21 years ago
|
||
Comment on attachment 123304 [details] [diff] [review] proposed fix r/sr/a=sspitzer
Attachment #123304 -
Flags: superreview+
Attachment #123304 -
Flags: review+
Attachment #123304 -
Flags: approval1.4+
Assignee | ||
Comment 27•21 years ago
|
||
fix checked in (that last patch wasn't quite right - I changed the 105.... to 65536 so I think it's finally right).
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 28•21 years ago
|
||
*** Bug 196787 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 29•21 years ago
|
||
If it is now fixed, how do I get a version of Mozilla that includes the fix?
Assignee | ||
Comment 30•21 years ago
|
||
download tomorrow's daily build (5/15/03), from www.mozilla.org, aka Nightly Builds.
Comment 31•21 years ago
|
||
*** Bug 205813 has been marked as a duplicate of this bug. ***
Comment 32•21 years ago
|
||
Trunk build 2003-05-20: WinMe, Mac 10.1.5, Linux RH 8 Verified Fixed. Views: Status|News, Status|Read, Status|Replied, Status Forward retained the criteria. Filters: Status|Replied, Label message as Blue retained the criteria.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•