Outlook add-in - attachment ID's not working correctly in desktop app, but work on web app

0
votes

I've developed an add-in for Outlook, it needs to be able to access attachments to emails.

On the desktop app, if I move an email with attachments from a shared folder to my main inbox, then try to run the add-in on it, i get the error:

The specified attachment Id is invalid.

However, if I perform exactly the same operation through the web app, it works fine.

I have checked and the Office.context.mailbox.item.itemId and Office.context.mailbox.item.attachments[i].id are exactly the same whether on web or desktop.

Emails with attachments that have not been moved from a different folder, and emails without attachments work fine.

I am fetching the attachment on a remote server through a PHP script, using a callback token I orginally get from Office.context.mailbox.getCallbackTokenAsync. The requests are made via EWS requests.

I am running Office 365 and the Outlook version is 1910 (Build 12130.20390), running on Windows 10.

Can somebody please help?

1
outlookoutlook-web-addins
Outlook desktop works in a cached mode so when you move an item to another folder, exchange is currently unaware of it because the sync hasn't kicked in. This is not the case for Outlook Online however since after the move exchange knows about it. If you wait for the desktop sync cycle to kick in, your scenario should work as expected after. – Outlook Add-ins Team - MSFT
Thanks for the response @OutlookAdd-insTeam. Is there a way for me to force a sync cycle, either through the add-in or some other way? – Jai Redden
There's no way to force a sync from an addin. Have you considered using docs.microsoft.com/en-us/office/dev/add-ins/reference/… to get the attachment content? Additionally, I am a bit curious that you noted emails without attachment work fine. Are you going a EWS getItem to get the emails as well? If so, you can also get the attachment id's from the getitem result. However, the sync delay still applies and getItem may not work if the item just moved. – Outlook Add-ins Team - MSFT
Thanks for the reply. I don't seem to be able to get the attachments using getAttachmentContentAsync - following the example on that page throws an error saying item.getAttachmentsAsync is not a function. According to this other reply here, getAttachmentContent is not implemented for OWA yet - is that still the case? I need this to work for both the desktop and web apps. – Jai Redden
Additionally, yes, im using an EWS getItem to get the emails too, but I'm not just fetching all of the attachments, only the ones the user specifies. So the process is this: Fetch email and attachment info in JS using the Office.context.mailbox.item object. Use that info to create a form, allowing the user to select which attachments they wish to interact with. Send that form to another server with the attachment details, and fetch those attachments via EWS, using the id's provided in the form. – Jai Redden

1 Answers

0
votes

After some helpful suggestions from @OutlookAdd-insTeam-MSFT, I've come to a solution for this.

The problem is, after moving a message from a shared folder to the main inbox, when using the desktop app, the Office.context.mailbox.item.attachments (created when we run Office.initialize) no longer returns the correct ID's, instead it seems to return the old cached/out of date ID's from before the email was moved. The ID's returned when using the web app are correct using this method.

However, requesting the ID's from the exchange server, via an EWS request (or a REST call, but I use EWS) always returns the correct attachment ID's, whether called from the web app or the desktop app.

So, the solution I have come to is to make sure and request all of the attachment ID's from the exchange server, rather than using the Office.context.mailbox.item object. It means adding in an extra step of having to get a callback token first to then be able to request the info from the exchange server, but it means you always get the correct ID's.

I hope this is of help to someone else.