After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 326252 - Applying "All Filters" to All Messages in Inbox fails badly
Applying "All Filters" to All Messages in Inbox fails badly
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
2.6.x
Other All
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[filters]
Depends on:
Blocks: 327508 327510
 
 
Reported: 2006-01-09 00:50 UTC by Patrick OCallaghan
Modified: 2013-09-13 00:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
filters.xml file (8.56 KB, text/plain)
2006-01-31 11:30 UTC, Patrick OCallaghan
Details
filters.xml file (17.35 KB, text/plain)
2006-01-31 14:11 UTC, Patrick OCallaghan
Details

Description Patrick OCallaghan 2006-01-09 00:50:02 UTC
Please describe the problem:
Ctrl-A Ctrl-Y in the Inbox (but nowhere else) causes a specific filter action to
apply to almost every message, even when none of them match the filter. Only one
message is left untouched, but it appears to be arbitrary. The filter action in
question is Refile+Stop. Inbox contents can be recovered by undeleting, but the
target folder has to be cleaned out by hand. The Inbox is on an IMAP server.

To test, I copied entire Inbox to a new folder on the same IMAP server and
applied Ctrl-A Ctrl-Y. Nothing happened. I tried it on a local folder and
nothing happened. I retried on the original Inbox and the bug reappeared. I
haven't tried it on a local Inbox.

Steps to reproduce:
1. Select Inbox on an IMAP server (or perhaps locally, don't know).
2. Apply Ctrl-A Ctrl-Y
3. Spend an hour or two cleaning up the mess.

Actual results:
Inbox is now empty except for one message, and some other folder has the Inbox
contents.


Expected results:
Given that no messages match the filter in the specific case tested, nothing
should happen.

Does this happen every time?
Yes (Evo 2.5.3 and 2.5.4)

Other information:
I enabled filter logging via gconf-edit. Every line of the log after truncating
and then carrying out the test follows this pattern:

Applied filter "SL" to message from <aaaaa> - "SUBJECT" at Sun, 08 Jan 2006 20:16:20
Action: Move to folder zzzzzzzzzzzzz/Lists/SL
Action: Stopped processing                                                     
                     Action: Stopped processing             

The "SL" filter is:
If
    Mailing List is FOO OR
    Recipients contains BAR OR
    Recipients contains BAZ OR
    Mailing List is ZILCH
Then
    Move To Folder Lists/SL
    Stop Processing
Comment 1 Poornima 2006-01-09 09:56:33 UTC
Not reproducible on evolution 2.5.4 on suse 9.3.
Comment 2 Patrick OCallaghan 2006-01-09 11:38:39 UTC
I'm on FC4 with all updates applied. The problem is totally reproducible on two different machines, one with Evo 2.5.3 and the other with 2.5.4, both against the same IMAP server and account. I'm going to try narrowing the Inbox to see if it's being caused by a specific message.
Comment 3 parthasarathi susarla 2006-01-31 08:49:30 UTC
hey patrick, can you attach the filters.xml file available in ~/.evolution/mail/

Changing to NEEDINFO, reopen with the necessary info
Comment 4 Patrick OCallaghan 2006-01-31 11:30:43 UTC
Created attachment 58459 [details]
filters.xml file

This is the filters.xml file from my home machine, as requested.
Comment 5 Patrick OCallaghan 2006-01-31 14:11:52 UTC
Created attachment 58467 [details]
filters.xml file

This is the filters.xml file from my office machine.
Comment 6 Jeffrey Stedfast 2006-04-17 18:38:12 UTC
        <part name="mlist">
          <value name="mlist-type" type="option" value="contains"/>
          <value name="mlist" type="string">
            <string>@solve.net.ve</string>
          </value>
        </part>

you can't do partial string matches in the mailing-list filter rule, it causes weird behaviours because of the way tokens are matched (they aren't compared like email addresses)

this might be the cause...
Comment 7 André Klapper 2006-07-03 14:09:18 UTC
i have no clue why this is set to NEEDINFO.
removing old milestone.
Comment 8 Tobias Mueller 2008-02-29 20:35:55 UTC
Hey Patrick,

is this this still an issue for you?
Comment 9 Patrick OCallaghan 2008-02-29 23:46:30 UTC
Nope, I haven't seen it in at least ayear.
Comment 10 Tobias Mueller 2008-03-01 09:56:03 UTC
I'll close it as OBSOLETE then.