Closed Bug 387337 Opened 18 years ago Closed 14 years ago

news server filters not working in SM 2.0a1

Categories

(MailNews Core :: Filters, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: nelson, Unassigned)

Details

(Keywords: regression, Whiteboard: rrange 2007-05-28 to 2007-07-08)

I have several news server accounts. For each one, I have setup filters that apply to the whole server, rather than applying to just one newsgroup. This all worked fine, until SM 2.0a1. Now, in SM 2.0a1, these filters do not work AT ALL. This began when I first switched to 2.0a1, and continues to the present. 100% reproducible.
At least a filter I have (watch thread if xxx..) works fine on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007071003 Thunderbird/3.0a1pre ID:2007071003
Nelson, what filter action? in thunderbird trunk, add star filter at server level WFM. but copy currently has a bug.
magnus, Nelson - do you have update newsgroup on a timer? or are you doing explicit "get new messages"? see bug 227224 comment 13
I usually just expand the server... no timer.
In reply to comment 3, I have the newsgroup prefs set to NOT fetch new messages automatically at startup, but to fetch them every 60 minutes. So, in each session, I initially expand the server's newsgroups. After that, a timer does it.
Still fully reproducible with trunk build from 2007-10-07 Filter is: if subject contains <string> then mark as read. It doesn't.
I tried this in Thunderbird - it worked. The code should be the same. Is it only server-level filters that aren't working for you, or are per-newsgroup filters also not working?
OK, it just happened to me again. Went to news server news://news.grc.com:119/ on which I am subscribed to 4 groups, including news://news.grc.com:119/grc.privacy news://news.grc.com:119/grc.security news://news.grc.com:119/grc.security.software news://news.grc.com:119/grc.techtalk I have a server-level set of filters for certain individuals who tend to post lots of messages that are nothing but quotations of and links to news articles from various web sites. The filters are all of the form: If the > From < > contains < > NAME < then take action > Mark as read < In each case, the name is the part outside of the "mailbox", e.g. if the full email address was fred <barney@betty> the filter is on fred, not on barney or betty I just went there tonight for the first time in a week or so. Now there are a whole bunch of new articles from the filtered authors in one of those newsgroups, not marked as read. Interestingly, in 3 of the 4 groups, the server filter seems to have worked, but in the fourth, it definitely did not work at all.
Correction: I wrote > in 3 of the 4 groups, the server filter seems to have worked, > but in the fourth, it definitely did not work at all. It did not work in any of the groups. The messages that I saw that were marked read were old messages that I marked read manually during the previous visit to this server, over a week earlier.
I think comment 9 was mistaken. It's difficult to tell which problems are due to this bug, and which are due to bug 400526. Please give urgent attention to bug 400526.
(In reply to comment #0) > This all worked fine, until SM 2.0a1. > Now, in SM 2.0a1, these filters do not work AT ALL. > This began when I first switched to 2.0a1, and continues to the present. Nelson, can you determine the regression range dates?
The last of the SM trunk 1.5a nightly builds was on 2007-05-28. I still run it on a laptop. AFAIK, it does not have this bug. (When I filed this bug, I believed it had not been present in any 1.5a builds. Perhaps I should double check that.) I filed this bug on 2007-07-08, at which time I was running a then-current SM 2.0a nightly build. So that's my first approximation of the regression date range. 2007-05-28 to 2007-07-08 But it's possible that the bug was present on some 2.0a (or "suiterunner") branch before that date.
Product: Core → MailNews Core
Nelson, harkening back to comment 7, does it work when set up as a per newsgroup filter? My brief test is mark as read works when run manual and specified as a newsgroup specific filter, and does not work as a server-wide filter. NoOp, can you reproduce?
Whiteboard: rrange 2007-05-28 to 2007-07-08
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090930 Lightning/1.0pre SeaMonkey/2.0pre Yes I can reproduce. Per comment #8 the filters do not work if the filter is set on the information outside of the <emailaddress>: From: fred <fred@barny> Filtering on 'fred' does not work. Only filtering on 'fred@barny' works. Better example so as not to confuse the 'fred' part: From: wally <fred@barny> Filtering on wally does not work (any filter action), only filtering on 'fred@barny' works. Also, filtering on 'wally <fred@barny>' does not work. This occurs on both individual newsgroup filters and per newserver filters.
David, Marco, possible for you check this News issue and narrow the current regression range of rrange 2007-05-28 to 2007-07-08 so something within a day or two?
Blocks: 519994
I just tried NoOp's steps with a clean profile in a SM trunk debug build under Linux [Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 SeaMonkey/2.1b3pre], and I cannot reproduce at all. Server: news.mozilla.org Group: mozilla.support.thunderbird Filter: [From] [contains] [murrell] => mark as read The filter is server-global. Everything works as expected, all posts by "Brian J. Murrell" <brian@xxx> [domain invalidated by me] are marked as read. Is this an issue still?
I just tested with a filter over on news.mozilla.test. I filtered on: From: NoOp (From header is: NoOp <glgxg@sbcglobal.net.invalid>) to mark the msg as read and tagged important. I also tested using all lowercase & no difference - both work. Works for me on 2.0.12 and 2.1b2 (both linux). I also tested on 2.1b2 on WinXP & that works as well. Tested both by downloading new messages from the reader, and by using 'Tools|Run Filters on Message' - both work. I reckon that this bug can be closed as fixed & can be reopened if anyone finds a regression.
Closing as WFM then, since we don't know what fixed it. Anybody feel free to reopen if you still encounter this issue, preferably with a test scenario based upon news.mozilla.org.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
No longer blocks: 519994
You need to log in before you can comment on or make changes to this bug.