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.

We use Office.js to build an Outlook web add-in and we make use of the calls composeItem.to.getAsync where the compose Item is Office.context.mailbox.item. The call returns an array of recipients of Office.EmailAddressDetails objects and are as described in this documentation.

In the latest version(s) of Windows Outlook (16.0.11901.20204 and 16.0.11901.20070), we can observe a discrepancy in the resulting EmailAddressDetails.recipientType to the above call when it comes to Dynamic Distribution Groups. We observe that the recipientType used to be distributionList on a slightly older version of Windows Outlook (16.0.11328.20362). But now, the recipientType returns other for Dynamic Distribution Groups. This discrepancy affects clients that are on different Windows Outlook update cycles.

Is this change going to be permanent or will it be using a value something other than other?

This affects how we implement our web add-in because we're concerned with figuring out groups (distribution lists, DDGs, etc.) from users and expanding the groups. As it stands right now, we're unsure whether other is within the category of expandable groups or not as there is no documentation regarding the details of recipientType values.

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

There was a checkbox in 'the old' OWA which, when checked, ensured that the Compose form (new message, reply, forward) opened in a popup. Please bring that functionality back.

The problem is that my read-pane add-in has a timer which the user can start to record the time spent on writing the reply to a message. I want to record that time in my application. When the compose form opens, the read-pane add-in gets closed and hence we lose the time spent. When the compose form opens in a popup, the read-pane add-in stays in its place and the user can save the time in our application.

NOTE This is impacting our existing customers.

I am unable to unregister a previously registered event handler for ItemChanged event when the handler function is no more available in the page's scope. So there needs to be an ability to either:
- unregister the event handler by name only or
- unregister all the event handlers registered by the add-in

Use Case
My add-in has more than one web-pages and I have a navigation bar in it. So my web-pages unload when I navigate to another page. Because the Office.context.mailbox.removeHandlerAsync function requires the named handler to be a valid function, I can not unregister the handler in another web-page where the user has navigated to. And when I try to register the event handler again (for that web-page), it fails because more than one handlers are not supported.

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.

Currently, the default solution of an Office Addins generates two projects that targets .NET Framework 4.6.x. Microsoft should change it to ASP.NET Core. There is a way to adapt the manifest file as seem in https://stackoverflow.com/questions/53991876/change-target-framework-of-a-office-addins-project-from-net-framework-to-net-c/53993432 , but It would be great if the keyword ~remoteAppUrl could refer to another address.
I see this might be a problem as .NET Core is optional when installing VS and might escalate to a broader discusstion.
Also, as asyncronous JavaScript code freaks out migrating VBA (and even web) developers, shouldn't the default template be already in TypeScript (or at least be in the wizard when creating a new solution) as shown in this link? https://github.com/OfficeDev/Excel-Add-In-TS-Start