Bug 474695 - Evolution generates bad rules in ~/.evolution/mail/filters.xml
Summary: Evolution generates bad rules in ~/.evolution/mail/filters.xml
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 10
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 475576 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-04 21:08 UTC by Mattias Ellert
Modified: 2008-12-27 23:26 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-12-18 00:37:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mattias Ellert 2008-12-04 21:08:41 UTC
Description of problem:

Evolution generates bad rules in ~/.evolution/mail/filters.xml.

Version-Release number of selected component (if applicable):

evolution-2.24.2-1.fc10.i386

How reproducible:

Always.

Steps to Reproduce:

1. Right-click on a message and select "Create rule from message"
2. Creating a "move to folder" filter where the destination is a folder on an imap server and press OK
3. Press ctrl-Y to execute to filter.
  
Actual results:

You get an error message:

Error while Filtering Selected Messages.
Cannot get folder 'INBOX/subfolder1/subfolder2': folder does not exist.

Message is not moved.

Expected results:

A working filter, no error.

Additional info:

If I edit the ~/.evolution/mail/filters.xml file in a text editor and change

    <rule enabled="true" grouping="any" source="incoming">
      <title>The mailinglist somelist</title>
      <partset>
        <part name="mlist">
          <value name="mlist-type" type="option" value="is"/>
          <value name="mlist" type="string">
            <string>somelist</string>
          </value>
        </part>
      </partset>
      <actionset>
        <part name="move-to-folder">
          <value name="folder" type="folder">
            <folder uri="email://local@local/INBOX/subfolder1/subfolder2"/>
          </value>
        </part>
      </actionset>
    </rule>

to

    <rule enabled="true" grouping="any" source="incoming">
      <title>The mailinglist somelist</title>
      <partset>
        <part name="mlist">
          <value name="mlist-type" type="option" value="is"/>
          <value name="mlist" type="string">
            <string>somelist</string>
          </value>
        </part>
      </partset>
      <actionset>
        <part name="move-to-folder">
          <value name="folder" type="folder">
            <folder uri="email://1228346718.3587.23/INBOX/subfolder1/subfolder2"/>
          </value>
        </part>
      </actionset>
    </rule>

the rule starts to work. I copied the string 1228346718.3587.23 from the .evolution/mail/config/folder-tree-expand-state.xml file.

It looks like evolution creates a rule to move the messages to a subfolder of the local inbox even if a subfolder of the inbox on the imap server is selected as the destination. When the filter is applied the destination folder does not exist.

Comment 1 Matthew Barnes 2008-12-04 21:33:16 UTC
I think this is a side-effect of [1], which was fixed today.

I'll backport the patch to the Fedora 10 evolution package.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=552583

Comment 2 Milan Crha 2008-12-09 18:00:45 UTC
*** Bug 475576 has been marked as a duplicate of this bug. ***

Comment 3 Matthew Barnes 2008-12-09 18:44:01 UTC
Give this a try.  I'm about to push it to the Testing repo.

http://kojipkgs.fedoraproject.org/packages/evolution/2.24.2/2.fc10/

Comment 4 Fedora Update System 2008-12-09 18:49:00 UTC
evolution-2.24.2-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/evolution-2.24.2-2.fc10

Comment 5 Fedora Update System 2008-12-11 07:58:32 UTC
evolution-2.24.2-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update evolution'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11142

Comment 6 Fedora Update System 2008-12-18 00:37:36 UTC
evolution-2.24.2-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Steevithak 2008-12-27 22:56:18 UTC
I just updated my Fedora 9 to Fedora 10 and all my mail filters stopped working. I assumed this was just a case of some non-backward-compatible change, so I deleted the filters.xml file and rebuilt all my filters one at time using the dialog found from File->Message Filters menu. But each time the filters are run, it still generates the same error messages, which look like this:

 Error while Filtering Selected Messages
 Cannot get folder 'Example Folder': folder does not exist.

I looked in the filters.xml file and it looks like the above example. All the folder locations are in the form:

 <folder uri="email://local@local/Example%20Folder"/>

A search on Google turned up this bug, which seems to match the problem I'm experiencing.

I have installed all the latest Fedora 10 updates. The evolution RPM is evolution-2.24.2-2.fc10.i386. The "About" dialog says Evolution 2.24.2. So it looks like the fix either didn't make it into this version or didn't fix the problem in all cases.

Comment 8 Steevithak 2008-12-27 23:26:07 UTC
Update: I've also confirmed I can manually fix the problem by doing the following:

1. Select the filter's destination folder in the left-hand pane of Evolution

2. Open the file ./evolution/mail/config/folder-tree-expand-state.xml

3. Copy the uri in the "selected" tag of the XML file.

4. Open the file ./evolution/mail/filters.xml

5. Paste the uri into the "folder" tag

Instead of "email://local@local/Example%20Folder" the uri now looks like "maildir:/home/steve/email#Example%20Folder"

I notice the uri includes the type of mailstore, so perhaps this bug was only fixed for the default mbox mailstore and not the other mailstore types? That might explain why the fix worked for some people but not me.


Note You need to log in before you can comment on or make changes to this bug.