Closed
Bug 85717
Opened 24 years ago
Closed 24 years ago
Some filters turn themselves off
Categories
(MailNews Core :: Filters, defect)
Tracking
(Not tracked)
People
(Reporter: lord, Assigned: naving)
Details
Attachments
(1 file)
10.91 KB,
image/gif
|
Details |
I use a lot of filters. There are two filters which like to turn themselves off.
I can reproduce as follows:
1. Turn the rogue two filters on.
2. Quit/restart
3. Look at filters -- they're still on
4. Get mail that uses those filters
5. Look at filters -- they're off again.
Of course, the filters in question are the ones that are part of my internal
spam catchers, so it's killing me. :-)
Are these filtering to folders which may have been deleted? In cases where the
folder path is invalid for a filter destination, the filter will disable. Base
problem I'm talking of is bug 41720.
Also occures on NetBSD/PPC with mozilla 0.9.1 (and 0.9 and ...).
The filteres are doing simple match and moves.
With 0.9, provided you remembered to re-enable the filters once they turned
themselves off things were mostly ok. With 0.9.1, I'm getting the feeling that
it is ignoring some filteres even when they are enabled.
More data:
Laurel asked me to see if my filters were pointing to folders that did not
exist. I checked to see (as best as you *can* see this from the UI) if the
filters pointed to dead folders. The UI strongly implied that things were in
order. The name of the destination folder was correct. However! I clicked on
the folder button and it opened the top level tree showing me my
"lord@netscape.com" and "lord@well.com" accounts. It did *not* pre-walk the
tree to show me where this folder was located.
So I manually reselected the correct destination folder, and things seem to work
now. I'll need to keep working for a day to make sure, but I'm pretty confident
this did the trick.
What happened? Here's the likely scenario:
-I use IMAP to access my lord@netscape.com email from both my home machine and
from my work machine. Each of these machines has slightly different filter
rules. Why? Because it's a royal pain to manually keep them in sync, and
sometimes I add/change a rule in one place and forget to make the same change at
the other place.
-I demoted a folder from it's top-level status to a lower level, sub-folder
status. I did this at home, where my filters lag behind. Since there was no
filter rule, there was no reason for the system to warn me that a rule needed to
take place. (It's also the reason the UI looked fine: I was pointing to the
correct name, but there was no there, there.)
-I went back to work, and checked email. The filter which had worked the other
day now could not because the folder had been pulled out from underneath it. So
the Mail Client decided to deactivate that filter.
Why is this a problem? I think the problem here is that a serious filter error
occurred, and I did not get any indication that things were broken. As a
result, hundreds of emails which normally get filtered now got left in my Inbox.
(Eudora lets you manually apply filters to messages in your Inbox, we should
too!)
One possible solution is for the client to warn me when this happens. Another
is for it to silently fail, but to redirect the filter to store in my Inbox (but
keeping it active). Then I'd notice that the rule was wrong, and I'd be able to
change it. Silently turning off is not a good solution.
Of course, that presumes that you can visually tell where the destination folder
is by looking at the UI. As I've mentioned, that's not currently the case.
(Why can't folders live on the IMAP server?)
Comment 5•24 years ago
|
||
This is interesting...
Lord, I definitely think we should warn the user when we can't apply such a
filter (Move to folder) due to a corrupt path or whatever.
This is, however, a duplicate of bug 41720. Please continue this discussion there.
*** This bug has been marked as a duplicate of 41720 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
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
•