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.

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.

A few months ago I've found a bug/limitation when developing Outlook Calendar Add-in. When time zone in Appointment organizer mode is changed (dropdown), the time returned by Office.context.mailbox.item.start.getAsync() is aggregated with the hours of the timezone, when the selected timezone itself is not available to get.

Let me clarify it with an example:

1. My location time zone is CEST. I open an event and set the time to 7:00 and timezone to Singapore.Image

2. then in the add-in I use Office.context.mailbox.item.start.getAsync() to get the start time. I receive the following string:

Thu Oct 25 2018 01:00:00 GMT+0200 (Central European Daylight Time)

As you can see it's added 8h to set time instead of changing a timezone.

I'd like to get the timezone set by the user or at least not shift the time. This is really misleading and causes time differences. I'd like to add that Office.context.mailbox.convertToUtcClientTime(); and Office.context.mailbox.convertToLocalClientTime() do nothing than converting from string to object.

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!