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.

Currently, there is an api called 'getTypeAsync' which can get the body type( 'html' or 'text' ). But there is no api to change the body type(for example, the api can be called 'setTypeAsync').

The reason why i need this api is for our customers user exprience. For example, when i use mac outlook client, i can get 'text' type by call 'getTypeAsync'. And i can only set plain text in the body by call 'setAsync'. when i try to set html, it can only return failed. But i think display html will be better for our customers. For example, Our customers can clearly see some hyperlinks, phone numbers, etc. what we want to show them. And can use their mouse to easily access our services without the need to copy plain text hyperlinks or phone numbers.

Actually, i noticed that windows 10 outlook client already implemented. And user can switch menu bar to 'Format Text', and can select paste 'As Html' , 'As plain Text' or 'As Rich Text'. I think maybe, it is only windows outlook client feature without mac.

I am developing an Web add-in which basically decrypts SMIME content and displays it to the user. To achieve this, I'm creating a new display form using either displayNewMessageForm or displayReplyForm and populating it with the content. This works fine for mail with not attachments. However for mail with attachments, it would be great if there was a mechanism to add the attachments to the form without having to upload it to some server first. Since adding attachments stored locally can already be done manually, I don't see why it is so difficult to implement some programmatic way of achieving this... Either by specifying the full path to the attachment, or providing the content bytes of the attachment (either way would server the purpose).

Please consider implementing this feature.

Thanks!

Please add ability to send email via Office JavaScript API.
For example, it can be a new 'send' method in Office.Item.

The main reason is an issue with Windows Outlook option "cached mode" and saving information in Exchange.

I my add-in I should make some changes in body of email and then send it. Currently, I see only one possibility how to do it this:

1. Save the email in Exchange via 'Office.context.mailbox.item.saveAsync()'.

2. But in cached mode I don't know when it really will be saved in Exchange. (see more info here https://officespdev.uservoice.com/forums/224641-feature-requests-and-feedback/suggestions/34593391-immediate-synced-to-the-server-saveasync-to-get). So I should periodically with some delays try to get information from Exchange via 'makeEwsRequestAsync'. And one more problem here is that updating Exchange can take 30-60 sec. My users very upset that sending emails is so slow. This is very hard to explain why the old .Net plugin worked well and a new one have these problems.
3. And only after this I can call EWS 'send' method via 'makeEwsRequestAsync'
So here are a lot of async requests and the main problem that this is very slow. This is very critical for my users. And sometime it's not very stable.

Please let me know if my workflow is to complicated and there is another way how to send emails via add-in.

Is it possible to add this new 'send' API which can resolve all these troubles ?

Thanks.