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:
Created attachment 691114 [details] Deleted Items view - Evolution
Created attachment 691115 [details] Deleted Items view - OWA
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).
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.
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
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.)
Created attachment 692917 [details] Evolution Debug Log
Created attachment 692918 [details] Evolution Receiving Preferences
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?
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.
(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.
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.
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.
Created attachment 694060 [details] Requested Log for "msgfolderroot" search
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.
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
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
Installed, tested, and can confirm this appears to have solved the problem. Thanks for the quick followup.