Outlook Add-in ErrorInvalidMailboxItemId - Item Id doesn't belong to the current mailbox when downloading attachments - outlook

We have an office add-in where we get contents of email, its attachments and send them to our SaaS application to be filed/saved. This works as expected until we try to retrieve attachments of an email from shard mailbox.
This has been working fine, but recently users have reported that they cannot. On testing, we found that, we can get the contents of the shared email (Body) but not the attachments (we can see that the add-in shows the email body and lists all attachments) but there is no attachment content, so when saved in the application, the email is saved with empty files.
The error we get when downloading attachment is:
{
"error": {
"code": "ErrorInvalidMailboxItemId",
"message": "Item Id doesn't belong to the current mailbox."
}
}
API Call:
https://outlook.office.com/api/v2.0/me/messages/<restId>/attachments/<attachmentId>/?$expand=Microsoft.OutlookServices.ItemAttachment/Item($expand=Microsoft.OutlookServices.Message/attachments
I've already had a look at this post but hasn't helped much. I am testing this on mac but will test on windows.
Any more info regarding this would be helpful.

For items from a Shared Mailbox, use the Shared Properties interface to construct the REST URL, as documented here. To determine whether to use Shared Properties or not, check for requirement set 1.8 as well as the existence of the getSharedPropertiesAsync method. For sample code on how to check for a requirement set, see this documentation.For sample code on how to check for and use the Shared Properties interface, see this other documentation.

Related

Outlook Add-in REST API In Shared Inbox Fails: ErrorInvalidMailboxItemId - Item Id doesn't belong to the current mailbox

We have an Outlook (Office JS) Add-in with a manifest configured to support shared folders, i.e.
<SupportsSharedFolders>true</SupportsSharedFolders>
The add-in has been running flawlessly, for many months, on a number of machines that meet the minimum requirement set of 1.8 for shared folder support. Since 22-Apr-2020 it has returned the following error when selecting an email in a shared email inbox:
Status Code: 404
ErrorInvalidMailboxItemId - Item Id doesn't belong to the current mailbox
The REST API call that returns this error is:
https://outlook.office.com/api/v2.0/me/messages/<RestID>/
Where <RestID> is created from: Office.context.mailbox.convertToRestId(Office.context.mailbox.item.itemId, Office.MailboxEnums.RestVersion.v2_0)
Has an API change been documented anywhere?
Do we need to modify our code?
This is not a recent change. The REST URL should be constructed based on the SharedProperties descrbied here https://learn.microsoft.com/en-us/javascript/api/outlook/office.sharedproperties?view=outlook-js-1.8 Note that the SharedProperties API is only available for shared items.

Outlook API, Message Moved to "Sent Items" still beign marked as "[Draft]"

I'm working on an Outlook Add-in, using office.js, where users can send secure emails using backend service.
In compose mode, when the user sends the email, using the add-in of course, the add-in will then move the message to "Sent Items" folder using the Outlook API /message/{id}/move and everything goes OK with the exception that the message in question still being marked as "Draft" by Outlook which is really annoying and does confuse the user who just sent the email by telling him that "this message hasn't been sent"
I searched through the API to see if there is a way to mark an email as "SENT" in order to prevent Outlook from showing this RED hint but with no luck so far!
So, My Question Is: Is there any way to overcome this misleading msg by marking the email as it was sent by Outlook?
Thanks in advance.
Finally, I was able to achieve a perfect solution for this challenge.
Based on:
#BrianClink's comment
This answer (Which uses Graph API but Outlook REST API): Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?
The approach/steps I followed to mark a mailItem as "SENT" (and not shown as 'draft') and put it in "SentItems" Folder are as follow:
First, Save the mailItem as "draft" using Office.context.mailbox.item.currentMail.saveAsync then retrieve its ID
Clone this draft mailItem properties eg: 'Sender', 'Subject', 'Body', 'ToRecipients'..etc so you get an exact copy of it.
With the newly cloned mailItem, add '[SingleValueExtendedProperties]' property with this value :
[
{
PropertyId: 'Integer 0x0E07',
Value: '1'
}
];
Serialize the new item as JSON and POST it to "sentitems" folder as follows:
xhr.open('POST', restHost + '/v2.0/me/MailFolders/sentitems/messages/');
xhr.send(clonedEmailJson);
On success, with xhr.status=201 [created], Remove the draft mailitem using a [DELETE] request
And you will end up having a new mail item created in your "sentItems" folder which appears as it was sent by Outlook :)
This was a very helpful solution to me because my users are using my add-in to send secure emails (using 3rd party API) and NOT Outlook, So, I wanted them to have the same UX/feeling as when they use Outlook.
Note:
Although the solution worked for me perfectly, it came with a price!
On slow internet connections or in case emails containing large attachments, the process can be remarkably slow, because the addin will first save the draft to the remote Exchange Server, get its ID, then duplicate it and send it again to the server, then remove the draft-ed one.

Logic Apps Email Trigger - Get original Alias

Found a very similar question here: Email aliases not returned as "To" address in logic app
TLDR: From within a logic app "When a new email arrives" trigger, How do I get the original alias that the email was sent to?
I have a logic app that creates a ticket based off an email sent to an outlook box. Now I want to be able to choose aspects of the ticket based off of whether or not the email was sent to the mailbox itself or an alias of the mailbox. The problem I'm having is that by the time logic apps gets a hold of the email, the alias address has already been replaced with the actual box's address ("alias1#place.com" -> "actualbox#place.com").
The actual mail in the inbox has the original email's alias information in the headers, but I can only get them by looking at the properties in outlook. I've tried to get the original "To" internetheader information both within logic apps (by exporting the email to blob storage and looking at headers there) and with the Microsoft Graph API. Sadly, the email exported by logic apps doesn't have the alias information and Graph API has pretty much every header but "To". At least one other person has lamented the lack of To
That said, the actual email still has the original alias information. Can someone help me get that information in logic apps without jumping through too many hoops? A many hoop solution is welcome if none other can be found though.
Use the Export email (V2) action from the Office 365 Outlook connector. This will give you the full message with original headers (including the actual To address)!
The flow here is, trigger on the incoming email, as you already are, then add the export email action providing the message id from that trigger to pull this specific email.
From there, you you'll have one big "body" property which you'll need to interrogate to find the To address.
Caveat on this though, it doesn't work when emails are sent between mailboxes in the same Office 365 tenant. Exchange Online will "helpfully" go, "I know that address... this is the address you wanted!"
What API are you using? In Outlook Object Model / MAPI / EWS, you need to retrieve the PR_TRANSPORT_MESSAGE_HEADERS MAPI property (DASL name http://schemas.microsoft.com/mapi/proptag/0x007D001F)
We arrived at a many hoop solution.
The "Primary" email box now has some rules that look at the internet headers mentioned above (Message -> Properties -> look for 'To:').
If it finds an alias there, it will put the email in a corresponding folder for each alias.
Then we have logic apps listening to each of the alias folders which will then send the email's information to the _Core logic app that does the actual processing.

Gmail New Threading Policy requires workaround - how to fix?

Per this announcement - https://gsuiteupdates.googleblog.com/2019/03/threading-changes-in-gmail-conversation-view.html -- an email with the exact same from/to and subject will no longer thread in Gmail if the emails are system generated unless we somehow reference the original message information in the subsequent system generated emails.
Does anyone have ideas for how we would do this in CDO mail using ASP / VBScript? Am guessing we would have to call a Google API to get the message ID after it created the message as well.
Google was not able to provide any help over and above the language used in this blog article which was as below:
Additional details
If you are managing a system that sends email notifications to users
and want your emails to be threaded in Gmail conversation view, then
you have to ensure that your notifications:
1) Have the same subject
2) Have reference headers that reference IDs seen earlier in the
thread, or have references headers that consistently refer to the same
message ID
Ideas are appreciated.
I'm not sure why you're looking for any sort of Google API, this sounds to be the standard "References" and "In-Reply-To" headers that any email reply should have. Refer to section 3.6.4 "Identification Fields" in RFC 5322. To create this you'd need to read the Message-ID header of the email being replied to and use it in the References header.
Just read the Message-ID of the email you're replying to like any other header:
Dim OriginalMessageId as String
OriginalMessageId = originalEmail.Fields.Item("urn:schemas:mailheader:message-id")
And use it to create the References headers in your new email:
replyEmail.Fields.Item("urn:schemas:mailheader:references") = OriginalMessageId
replyEmail.Fields.Item("urn:schemas:mailheader:in-reply-to") = OriginalMessageId
If you need more of a pointer of how this would work, you might need to include more of the code of how you're reading a message and how you're replying to it.

Outlook sent item internet header missing

I have written a C++ app that sync's Outlook emails with our central server DB. Incoming messages contain MessageID info in the internet header - I use this for key generation when placing the messages in the central DB. However, Sent Items in Outlook do not seem to have Internet Headers, so I am stuck for a static id I can use to generate a unique, static GUID for placing the message in the central DB. Multiple Outlook stores are being scanned for multiple users, each user running a copy of the sync program. To be clear, if Pete sends an email to Joe, the email in Pete's Sent Items folder needs the same id to be generated as the id generated for the email when it arrives in Joes Inbox folder - Pete & Joe are both running the sync software.
Does anyone know whether:
1. You can grab a static MessageID from a Sent Items email item
2. If not, is there another value within the Sent Items email that will be available to the sync app scanning the Sent Items folder, and available to the sync app scanning the Inbox that the email eventually arrives in.
Users could be running Outlook 2002 upwards.
Thanks very much.
The MAPI property PR_INTERNET_MESSAGE_ID is set for outgoing and incoming items.

Resources