Bug 906484 - Deleting items in "Deleted Items" does not remove them from Exchange server
Summary: Deleting items in "Deleted Items" does not remove them from Exchange server
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution-ews
Version: 18
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-31 17:23 UTC by Adam D.
Modified: 2013-02-07 21:41 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-02-07 10:25:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Deleted Items view - Evolution (82.60 KB, image/png)
2013-01-31 17:23 UTC, Adam D.
no flags Details
Deleted Items view - OWA (227.74 KB, image/png)
2013-01-31 17:24 UTC, Adam D.
no flags Details
Evolution Debug Log (557.82 KB, text/plain)
2013-02-04 18:10 UTC, Adam D.
no flags Details
Evolution Receiving Preferences (57.19 KB, image/png)
2013-02-04 18:10 UTC, Adam D.
no flags Details
Requested Log for "msgfolderroot" search (10.02 KB, text/plain)
2013-02-06 17:46 UTC, Adam D.
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 693306 0 None None None Never

Description Adam D. 2013-01-31 17:23:17 UTC
Description of problem:
In Fedora 18, connecting to Exchange 2007 (SP4, I believe, I can verify if needed.) with evolution-ews. If I delete things from my Inbox in Evolution, they are correctly moved to Deleted Items both locally and on the server. However, if I then delete them from Deleted Items, they disappear from the local Evolution, but not from Exchange, where I must log in to OWA or Outlook on a different machine, or remove from my phone to fully delete. I have attached screenshots to show to illustrate what I'm referring to. Both are taken moments after deleting a folder full of items from Evolution's "Deleted Items" EWS folder.

Version-Release number of selected component (if applicable):
evolution-data-server-3.6.2-3.fc18.x86_64
evolution-3.6.2-3.fc18.x86_64
evolution-ews-3.6.1-1.fc18.x86_64

How reproducible:
Every time I delete anything.

Steps to Reproduce:
1. Delete item from Inbox.
2. Delete item from Deleted Items.
3. Deleted item doesn't remove from server.
  
Actual results:
Deleted items remain in server-side mailbox, taking up space.

Expected results:
Deleted items expunged from account.

Additional info:

Comment 1 Adam D. 2013-01-31 17:23:47 UTC
Created attachment 691114 [details]
Deleted Items view - Evolution

Comment 2 Adam D. 2013-01-31 17:24:10 UTC
Created attachment 691115 [details]
Deleted Items view - OWA

Comment 3 Milan Crha 2013-02-01 08:22:36 UTC
Thanks for a bug report. I tried to reproduce this, but it works fine for me. There is one thing, though, the message is fully deleted only after the changes in the folder are saved, which usually happens when you move away from the folder, thus what I did was:
a) Delete a message in evolution in Deleted Items
b) move to a different folder, it doesn't matter where
   - now the deletion request is propagated to the server
c) open OWA and check the message is gone from the Deleted Items

Mine server is Exchange 2010, though it would be surprising if it matters.

Could you retest with the explicit folder change, please? You can also select View->Show Deleted Messages, then you'll see which messages a re "scheduled" for deletion (those will be stroke out).

Comment 4 Adam D. 2013-02-01 21:09:30 UTC
Thanks for the follow-up. I just tested this on some updated versions of software:

evolution-3.6.3-2.fc18.x86_64
evolution-ews-3.6.3-1.fc18.x86_64
evolution-data-server-3.6.3-1.fc18.x86_64


I still have the problem; I tried the prescribed method, but it still acts the same. Delete item from inbox, go to Deleted Items. Delete it from Evolution, switch back to Inbox. It's still there on the server. If I go back to Deleted Items and turn on "Show Deleted Messages", it's not listed.

I checked my local server, and I see we're on Exchange 2007 SP2, Update Rollup 5; the latest seems to be SP3 UR9. I'll be updating our server over the weekend to the latest versions, but I can report that under Fedora 17's versions of the above software, it did work as expected.

If there's anything else I can test, let me know. Thanks.

Comment 5 Milan Crha 2013-02-04 07:45:00 UTC
In that case, please run evolution with EWS debugging on, which will give you raw communication between your server and the client, where will be shown DeleteItem request with DeleteType either "MoveToDeletedItems" (when deleting in Inbox), or "HardDelete" (when deleting in Deleted Items folder). The later probably failed for some reason, which you may see in the log.

The command to run evolution with debugging on is:
   $ EWS_DEBUG=2 evolution &>log.txt

Comment 6 Adam D. 2013-02-04 18:09:18 UTC
I've attached the sanitized logfile; I can see the MovetoDeletedItems request, but there's no HardDelete when I actually delete something. The log consists of me opening the program, selecting a mail item, deleting it. Then deleting it from Deleted Items, and then switching to another folder.

As a separate attempt, I removed my ~/.config/evolution folder and set it up and re-synchronized my mail and get the same results. I'm also attaching a screenshot of my receiving preferences (I don't think that has anything to do with it.)

Comment 7 Adam D. 2013-02-04 18:10:11 UTC
Created attachment 692917 [details]
Evolution Debug Log

Comment 8 Adam D. 2013-02-04 18:10:42 UTC
Created attachment 692918 [details]
Evolution Receiving Preferences

Comment 9 Milan Crha 2013-02-05 11:44:27 UTC
I think the only way would be that the EWS plugin didn't recognize your Delete Items folder as a Trash folder, thus when you delete a message in Deleted Items it thinks you are in a regular folder, and deletes the message with a move to Deleted Items. The Exchange server doesn't claim an error on this, while I'd expect it will. Nonetheless, is your Deleted Items EWS folder shown in the folder tree on the left with a Bin icon, the same as On This Computer/Trash folder?

Comment 10 Adam D. 2013-02-05 18:57:16 UTC
It is not; I just updated my server last night to latest Exchange release, so I'm going to try and remove all my config info again and set it up. I'll post back shortly.

Comment 11 Adam D. 2013-02-05 19:10:37 UTC
(In reply to comment #10)
> It is not; I just updated my server last night to latest Exchange release,
> so I'm going to try and remove all my config info again and set it up. I'll
> post back shortly.

Just tried it again, same behavior. My Deleted Items folder is just a regular folder. The only one with "special" icons are Drafts and Sent Items... which is odd, because by default when I set it up, the defaults for the account for where to send those items is "On My Computer", and not under my Exchange account, as logic would dictate. That might be a separate issue, though.

Comment 12 Milan Crha 2013-02-06 07:14:37 UTC
OK, so that's it, the folder is not recognized as a Deleted Items folder, thus it doesn't permanently delete messages from there. The folder type decision is made based on returned default folder IDs. I'll check whether there will be anything obvious about that part of the code.

Comment 13 Milan Crha 2013-02-06 08:33:59 UTC
Hmm, I guess the evolution-ews failed to get all the expected standard folders, thus it didn't update local flags properly.

Could you:
a) close evolution
b) clear your local mail cache, which is located at
   ~/.cache/evolution/mail/<ews-account-uid>/
   you can find the right folder based on its content, the EWS based caches
   have there a file named "folder-tree", where is stored list of currently known
   folders
c) then run evolution with EWS debugging on,
    $ EWS_DEBUG=2 evolution -c mail &>log.txt
d) wait until it's done and your EWS folders are shown
e) close evolution

Search the log.txt file for "msgfolderroot", it might be there not more than twice, and after it a response. I guess it didn't return all the folder IDs for you, or ended with some error there.

Please attach here the part with a request and response, or the returned response errors from the log. Thanks in advance. If I'm right, then maybe there will be a chance to make the code a bit more robust, to not fail on itself if one of the standard folders is not reachable.

Comment 14 Adam D. 2013-02-06 17:46:58 UTC
Created attachment 694060 [details]
Requested Log for "msgfolderroot" search

Comment 15 Adam D. 2013-02-06 18:13:45 UTC
As a note, I put the breaks in the log after each block, since I was trying to take a look at the log to see if I noticed anything out of order; I see there is an error listed there, but it doesn't seem to have a folder ID associated. Here's the folder ID part of the log for Deleted Items:

            <t:Create>
              <t:Folder>
                <t:FolderId Id="AAMkAGM2MDQ2ODMwLWQ1MzUtNGFjYy1hNmIyLWM0NDg0MGY5YWYxYgAuAAAAAADlTh0fqFMCTLf3YnwyWYl6AQAIPZcOpV1FRIkLOgURPgU/AAAAKONtAAA=" ChangeKey="AQAAABYAAABSk5o0JwE2Q6EtkFxlyLHAAAN/9QcN"/>
                <t:ParentFolderId Id="AAMkAGM2MDQ2ODMwLWQ1MzUtNGFjYy1hNmIyLWM0NDg0MGY5YWYxYgAuAAAAAADlTh0fqFMCTLf3YnwyWYl6AQAIPZcOpV1FRIkLOgURPgU/AAAAKONnAAA=" ChangeKey="AQAAAA=="/>
                <t:FolderClass>IPF.Note</t:FolderClass>
                <t:DisplayName>Deleted Items</t:DisplayName>
                <t:TotalCount>51</t:TotalCount>
                <t:ChildFolderCount>0</t:ChildFolderCount>
                <t:EffectiveRights>
                  <t:CreateAssociated>true</t:CreateAssociated>
                  <t:CreateContents>true</t:CreateContents>
                  <t:CreateHierarchy>true</t:CreateHierarchy>
                  <t:Delete>true</t:Delete>
                  <t:Modify>true</t:Modify>
                  <t:Read>true</t:Read>
                </t:EffectiveRights>
                <t:PermissionSet>
                  <t:Permissions>
                    <t:Permission>
                      <t:UserId>
                        <t:DistinguishedUser>Default</t:DistinguishedUser>
                      </t:UserId>
                      <t:CanCreateItems>false</t:CanCreateItems>
                      <t:CanCreateSubFolders>false</t:CanCreateSubFolders>
                      <t:IsFolderOwner>false</t:IsFolderOwner>
                      <t:IsFolderVisible>false</t:IsFolderVisible>
                      <t:IsFolderContact>false</t:IsFolderContact>
                      <t:EditItems>None</t:EditItems>
                      <t:DeleteItems>None</t:DeleteItems>
                      <t:ReadItems>None</t:ReadItems>
                      <t:PermissionLevel>None</t:PermissionLevel>
                    </t:Permission>
                    <t:Permission>
                      <t:UserId>
                        <t:DistinguishedUser>Anonymous</t:DistinguishedUser>
                      </t:UserId>
                      <t:CanCreateItems>false</t:CanCreateItems>
                      <t:CanCreateSubFolders>false</t:CanCreateSubFolders>
                      <t:IsFolderOwner>false</t:IsFolderOwner>
                      <t:IsFolderVisible>false</t:IsFolderVisible>
                      <t:IsFolderContact>false</t:IsFolderContact>
                      <t:EditItems>None</t:EditItems>
                      <t:DeleteItems>None</t:DeleteItems>
                      <t:ReadItems>None</t:ReadItems>
                      <t:PermissionLevel>None</t:PermissionLevel>
                    </t:Permission>
                  </t:Permissions>
                </t:PermissionSet>
                <t:UnreadCount>0</t:UnreadCount>
              </t:Folder>
            </t:Create>

Thanks.

Comment 16 Milan Crha 2013-02-07 10:25:49 UTC
Nice, thanks for the update. If I count the folder right, then it failed to find a 'journal' standard folder. It explains why it doesn't work for you, one missing folder and all the checking for proper folder type is lost.

I'm moving this upstream at [1], feel free too CC there for any further updates. I'll provide a test package of evolution-ews (it'll require to refetch folder structure again), when there will be available an upstream fix.

Thanks for your help with all the investigation on this.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=693306

Comment 17 Milan Crha 2013-02-07 17:54:09 UTC
Here [1] is the test build with the upstream patch. Please make sure you'll have your the local mail folder cache deleted, thus the initial fetching will be done. If everything will work correctly, then you've a special icons on the Inbox and Deleted Items folders, and when you delete a message in the Deleted Items folder then it'll be removed from the server as well.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4936718

Comment 18 Adam D. 2013-02-07 21:41:41 UTC
Installed, tested, and can confirm this appears to have solved the problem. Thanks for the quick followup.


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