Ok so I have a Blob file that I'm trying to save on local disk (the Blob is created locally from an ArrayBuffer). The problem I'm facing is that Outlook for macOS does not want to open a FileSaverDialog or something similar to let the user save the file.

My code is working perfectly in Outlook for Web (OWA) on all browsers (including Safari) and Outlook for Windows.

const blob = new Blob([body]); //body is an ArrayBuffer created locally
const link = document.createElement('a');
if (link.download !== undefined) {
const url = URL.createObjectURL(blob);
link.setAttribute('href', url);
link.setAttribute('download', fileName);
link.style.visibility = 'hidden';
document.body.appendChild(link);
link.click();
document.body.removeChild(link);
}

PS: I have tried using window.open(blob);, but Outlook for macOS throws an error in that situation: "There is no application set to open URL blob:https://..."

PS 2: I have also tried using Office.context.ui.displayDialogAsync(url, { height: 100, width: 100, requireHTTPS: true });,but still getting the same error.

How am I supposed to prompt a SaveFileDialog for the user ? Thank you in advance

We have been told that support for add-ins in shared mailboxes will be added to Outlook in Q2/Q3 of 2019. Thus, we have started rolling out support for shared mailboxes in our add-in too.

As part of this, we have noticed that the add-in icons are only rendered in the context of a shared mailbox element if the user is in the _old look_ of Web Outlook.

Since more and more people will be using the _new look_ as default, users should be able to invoke the add-ins via the new look too.

Please add support for rendering the add-in icons in the _new look_ of Web Outlook too in the context of shared mailboxes.

To anyone who wants a temporary work around: it is currently possible to open an add-in a shared mailbox context in the _new look_ by opening the add-in a personal mail box context, pinning it, and then navigating to a shared mailbox item.

With the preview release of "the new Outlook" on OWA, Office Add-ins are now buried in the drop down context menu in an email. Additionally, it appears they do not follow the same behavior of Outlook on the desktop, where Office Add-ins will show in the larger ribbon if used more frequently.

According to this article, Office Add-ins can be pinned if they are used frequently:

If you were using add-ins in the classic Outlook on the web experience, they will show up pinned next to mail actions or in the drop-down menu once you open an email in the new experience. You can also install more add-ins from the Office Store—simply open an email, click the drop-down menu, and select Get Add-ins. Once installed, add-ins will show up in the drop-down menu. You can also choose to pin frequently used add-ins.
While I can instruct users to pin this for themselves, it does not appear that Office Add-ins can be pinned by an administrator.

For this feature, it would be great for administrators to be able to customize which add-ins are immediately available to the user by pinning them. Office Add-ins being buried in the menu of OWA is not helpful in this regard.

Adding an attachment via addFileAttachmentAsync is currently very limited in how it handles authentication, for 2 reasons:
1) When Outlook (desktop application, not OWA) requests the attachment, it first does an OPTIONS call, which is good, but does not set an Origin header, which is bad. This means CORS rules cannot be enforced properly.
2) Outlook seems to also always set an "Authorization" header with value "Bearer" when requesting the file. It is common though to specify the authentication tokens as query string parameters. In this case, the server receives both an Authorization header and authentications tokens in the query string, and fails (e.g. in the case of S3).

With these 2 gaps, and the inability to attach as an array of bytes, the capabilities are very limited.

Copied from : https://stackoverflow.com/questions/46671562/how-can-we-force-a-mailbox-item-to-be-persisted-to-ews?rq=1

Note: This particular issue has significant impact on our customers, which translates to high business impact with direct consequences on revenue.

TL;DR.
How can our Office add-in for Outlook, when a user interacts with our add-in while composing an email draft, minimize the amount of time it takes before the EWS GetItem API will return an OK response for the itemId we receive from Office.context.mailbox.item.saveAsync()?

If it turns out that our add-in has no control over when the item will be persisted to EWS, then what could an end-user do to speed this up?

We are looking for either (a) a technical solution, or (b) messaging to instruct our customers on how to mitigate/fix/work around this issue.

End-User Impact
Some of our customers are unable to send emails using our Office add-in for Outlook, or have to wait an exceedingly long time (> 2 minutes) before their email will send.

Our Goal
We want all of our customers to be able to send emails using our add-in, without having to wait for an unreasonable amount of time.

Additional Context
Based on our logs and customer reports, this issue only exists in the Outlook 2016 for Windows desktop application. We have no evidence to suggest the issue is present in any other version of Outlook, including Outlook 2013 or Outlook for Mac, however it is possible that the issue may be present in those clients as well.

Overview of our add-in
Our add-in integrates with Compose mode to provide additional functionality while composing email messages, such as templates, follow-ups, open and click tracking, and scheduling.

Our add-in works in tandem with our SaaS product like this:

Our add-in sets EWS extended properties on the email message with metadata indicating which features are enabled on that message.

Our SaaS product, out of band, is configured to read from the customer's mailbox via the EWS API. When it encounters EWS extended properties our Office add-in has written, it triggers the code paths to satisfy the desired behavior.

Root Cause Analysis
The root cause of our problem is our interaction with EWS in Outlook 2016 for Windows. In order to successfully interact with EWS to read/write to a mailbox item, it must be aware of that item.

The documentation for Office.context.mailbox.item.saveAsync() says:

In Outlook Web App or Outlook in online mode, the item is saved to the server. In Outlook in cached mode, the item is saved to the local cache.

It goes on further to say:

Note: If your add-in calls saveAsync on an item in compose mode in order to get an itemId to use with EWS or the REST API, be aware that when Outlook is in cached mode, it may take some time before the item is actually synced to the server. Until the item is synced, using the itemId will return an error.

Thus, we have concluded that Office.context.mailbox.item.saveAsync(), although it does indeed return an eventually valid itemId, does not guarantee that any subsequent EWS interaction will succeed. So far, we have found no way to accelerate the process of the Outlook client actually making EWS aware of the mailbox item.

Mitigation
We have attempted to mitigate this problem by polling EWS GetItem to attempt to obtain a ChangeKey for the item with the itemId we receive from Office.context.mailbox.item.saveAsync(). While we have seen that this does eventually succeed, it may take a minute or longer before this occurs. That is simply far too much time for our customers to have to wait.

Understanding "online mode" vs "cached mode"
If the Outlook 2016 for Windows desktop client is in "cached mode", is there anything the user can do to:

…know whether the client is in "cached mode" or "online mode"?
…attempt to force the client into "online mode"?

You used to save and display all of the email addresses that I would use while managing emails. I find it so frustrating that you now limit this list to the last five emails. I am constantly emailing people that I haven't spoken to in six months or so. The recent emails doesn't help.

My work around is to go to my laptop and search for someone and then find their email. It used to be that this would just drop down.

I don't know why you changed this feature. But I waste 10 minutes EVERY DAY searching for email addresses that used to be readily avialble. Often while I am searching for these addresses i am cursing Microsoft for making this change.

Would you please change it back to the way it used to be. I just lost 5 minutes waitng for my laptop scrolling through the 1000's of emails I have trying to fing the email address of someone i haven't communicated with in six months. It just WASTES so much time.

Please go back to the way it used to be.

Hello,

I’m working on a web add-in for Microsoft Outlook, and I’ve run into a few issues with Office.js’s body.setAsync() method.

I’ve posted two questions to Stack Overflow related to my add-in’s use of the body.setAsync() method:

- Base 64 signature images in the Outlook Web App are lost when I try to update the body of an email [link: https://stackoverflow.com/questions/51736434/how-to-prevent-base-64-format-signature-images-being-dropped-in-outlook-web-app]

- Getting the email body with body.getAsync() and then setting it with body.setAsync() causes line spacing issues in desktop Outlook platforms that use Word as the text editor [link: https://stackoverflow.com/questions/51603265/line-spacing-increased-issue-when-updating-email-body-with-office-js]

My add-in needs to add content to the end of the email, and looking at the methods available to us on the body object in office.js, it looks like using body.setAsync() to replace the entire email body is the only way I can reliably add new content to the end of the email.

We know there is a body.prependAsync() method already and would like to request a body.appendAsync() method that added content to the end of the existing email body. This would solve the issue I’ve been having with dropped signature images. Being able to append content to the end of an email would also allow me to avoid the line spacing issue because I wouldn’t have to reset the entire body content of the email.

If there are no plans to add a body.appendAsync() method, is there any other workaround you’d suggest for adding content to the end of an email without us dropping Base 64 images from users’ signatures?

Thank you!