GNOME Bugzilla – Bug 561794
Store sent messages in Sent Items, not Outbox
Last modified: 2009-12-11 06:25:27 UTC
Please describe the problem: The messages newly sent or replied or forwarded from Evolution are not getting stored in Sent items folder. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
And outbox doesn't get flushed eventhough the mails are delivered.
Similar bug reported to Fedora: http://bugzilla.redhat.com/show_bug.cgi?id=505671 With evolution-mapi from rawhide, copies of sent messages don't appear to be saved anywhere, and the account preferences don't let you set the folder into which they should be deposited.
@@ -490,9 +494,10 @@ mapi_message_item_send (MapiItem *item, GSList *attachments, GSList *recipients) guint64 fid = 0; mapi_id_t mid = 0; - mid = exchange_mapi_create_item (olFolderOutbox, fid, NULL, NULL, + /* mid = exchange_mapi_create_item (olFolderOutbox, fid, NULL, NULL, */ + mid = exchange_mapi_create_item (olFolderSentMail, fid, NULL, NULL, mail_build_props, item, recipients, - item->attachments, item->generic_streams, 0); + item->attachments, item->generic_streams, MAP I_OPTIONS_MOVE_TO_SENTITEMS); return mid; } Seems to solve the issue. But i'm not sure how correct is this. Currently trying out another approach by setting PR_SENTMAIL_ENTRY_ID.
Can we have this fixed soon, please? Without this, MAPI support is pretty useless.
I would use only the first part, use olFolderSentMail instead of olFolderOutbox in there. It seems to work fine for me, and the similar approach is using also openchangeclient, though there's a comment: > /* Get Sent Items folder but should be using olFolderOutbox */ Nonetheless the change seems to work fine.
So, any chance of this being committed?
Ah, I'm sorry for a late update, Jony told me IRC that I'm wrong, his other approach with PR_SENTMAIL_ENTRY_ID, as mentioned in comment #3, is a correct fix.
Created attachment 148189 [details] test patch for evolution-mapi; This is strange. Based on the article http://msdn.microsoft.com/en-us/library/bb446027.aspx the PR_ENTRYID is supposed to be present on a folder object, but I do not have it received with libmapi, it returns MAPI_E_NOT_FOUND (0x8004010f). When I try to ask the store for its PR_IPM_SENTMAIL_ENTRYID, then I get success on a fetch of it (the call of GetProps), but it fails in the prop itself, with MAPI_E_NO_ACCESS (0x80070005). How is that possible? My openchange version is openchange-0.8.2, is it too old? And one other thing, I hope the call of SetProps can be done multiple times on an object, as otherwise the change would be very different.
Created attachment 148330 [details] other approach for evolution-mapi; After an IRC chat with Kerihuel I was told that it's possible the fetching for EntryID can be broken, but more investigation is needed to be sure. Meanwhile I was adviced to try to copy the message from Outbox to Sent Items after successful SubmitMessage call on my own, but it fails as well, with MAPI_E_SUBMITTED error, even the message is still in the Outbox. I've no idea what to do now.
Created attachment 148336 [details] [review] proposed ema patch for evolution-mapi; After another discussion with Kerihuel it turned out that the issue with the above "other approach" patch was that the obj_message was still there, preventing the message from the movement. Releasing it before move call fixed that. Nonetheless, after some observations, the problem with an Outbox remote folder is kinda big, because Evolution is not using a remote Outbox, but its own local Outbox, under its On This Computer. Thus when SubmitMessage reports an error, the message is kept in the local Outbox, as well as in the remote Outbox, which is obviously wrong. Issue with movement is that the ema's exchange_mapi_create_item returns a message id of a newly created message, but after movement to the Sent Items the message no longer exists, which might cause a trouble and it is not as that simple to get the moved message ID. Thus I decided the approach of storing message to Sent Items folder before submitting, and if the submit fails, then remove it from the Sent Items folder. This might cover all the above mentioned issues and simplifies things quite much. I would like to ask Jony on his thoughts and anyone being able to test this patch on a real environment, with real recipients, to give it a try. Thanks in advance.
Silly question: while this is being fixed, is there are workaround for the current Evo? BCC to yourself + filter or something like that?
(In reply to comment #11) > Silly question: while this is being fixed, is there are workaround for the > current Evo? BCC to yourself + filter or something like that? Messages are stored in your MAPI/Outbox folder, thus some rule with "Location=MAPI/Outbox => Move to MAPI/Sent Items" and from time to time going to Outbox and selecting all messages and doing Message->Apply filters (basically going to MAPI/Outbox and Ctrl+A, Ctrl+Y) might do the ugly job for you, before the fix will be approved and committed to sources.
(In reply to comment #12) > Messages are stored in your MAPI/Outbox folder, thus some rule with > "Location=MAPI/Outbox => Move to MAPI/Sent Items" and from time to time going > to Outbox and selecting all messages and doing Message->Apply filters > (basically going to MAPI/Outbox and Ctrl+A, Ctrl+Y) might do the ugly job for > you, before the fix will be approved and committed to sources. So, what you're saying here is that all the sent messages actually do get stored in MAPI/Outbox and do not get deleted. If that's the case, I can then easily move them by hand. Let me test.
Patch attached in comment#10 seems to work fine for me. Just a trival issue, when i reply to any message, i see two Re: in sent item.
(In reply to comment #13) > So, what you're saying here is that all the sent messages actually do get > stored in MAPI/Outbox and do not get deleted. If that's the case, I can then > easily move them by hand. Let me test. Yeah, you are right. The messages end up and stay in MAPI/Outbox. I haven't noticed that before. Interesting. Now, let's see what Outlook does with them. I'm guessing it's going to send them out again.
(In reply to comment #15) > I'm guessing it's going to send them out again. It doesn't actually. OK, I'll just move stuff by hand now. For some reason, outgoing filtering doesn't work for this (not very important - fix is in the works).
(In reply to comment #14) > Patch attached in comment#10 seems to work fine for me. Just a trival issue, > when i reply to any message, i see two Re: in sent item. Thanks for testing this. The double "Re:" in subject, I bet I saw a bug report about that already. (In reply to comment #16) > (In reply to comment #15) > (In reply to comment #13) :)
Created commit 3ca475d in ema master (0.29.3+) Created commit 81e6266 in ema gnome-2-28 (0.28.2+)
Created commit bd83dea in ema master with a comment as Jony asked me.
Created a openchange ticket for no access to EntryID : http://trac.openchange.org/ticket/222