Bug in Outlook add-in commands showing command label instead of the add-in title on first use in a session
It seems there is a bug with the Outlook add-in commands when using the add-in from Outlook Web Access.
When using the add-in command (ribbon button) to open a task pane to show your add-in the label of the command button is shown at the top of the add-in where the add-in title should be. If you close the add-in and use the command button subsequent times in a session, then the add-ins title is correctly displayed.
Refreshing the browser window and again trying to use the add-in with show the command button label again (but just the first time the add-in is used).
I have been able to reproduce this issue with the Command Demo add-in from the Office Dev site:
1. Clone from GitHub https://github.com/jasonjoh/command-demo
2. Run locally using gulp serve-static (as per instructions in the GitHub repo)
3. Deploy the add-in manifest (as per instructions in the GitHub repo)
On first use of the add-in in a session (or after refreshing the browser window) the add-in title uses the label of the command button. In the case below the button label of “Display all properties” is shown.
If you close the add-in and then click on the same command button subsequent times then the correct add-in title of “Add-in Command Demo” is displayed.
This bug only seems to affect OWA, Desktop Outlook 2016 consistently displays the correct add-in title as shown below.
It would also be nice if the header we displayed in Desktop Outlook was consistent with OWA. As you can see from the screenshots above OWA shows the add-in icon in the header whereas Desktop Outlook just has the title without an icon.
I’ve logged this bug on UserVoice, if it’s causing pain for you please vote it up!
SharePoint 2007 and SharePoint 2010 had a series of Web Parts dedicated to surfacing and interacting with an Exchange mail account directly from a page in SharePoint.
Overview of the Outlook Web Access Web Parts (for SharePoint 2007 and 2010)
If you are not familiar with the functionality here’s a quick overview (this info is taken from the official Microsoft help documentation http://office.microsoft.com/en-us/sharepoint-foundation-help/working-with-outlook-web-access-web-parts-HA101810215.aspx)
There are five Outlook Web Access Web Parts. These can be used with Microsoft Exchange Server version 2003 to 2007:
- My Calendar
- My Contacts
- My Tasks
- My Inbox
- My Mail Folder
These Web Parts are most useful for your My Site, because only you (or someone who can log into your Exchange e-mail account) will be able to see the information from your folders. If you put one of these Web Parts on a shared site, other users will see the Outlook Web Access logon screen in the Web Part.
Each Web Part displays the information from a folder in your email account, so you can choose the information you want to show on your site. The Web Parts make it easy to show specific information, such as tasks, without showing all of your Outlook information. If you want to have full Outlook functionality on your SharePoint site, you can use a Page View Web Part linked to the URL for your Outlook Web Access server.
All of the Outlook Web Access Web Parts provide two-way communication with your Exchange Server e-mail account: Changes you make in a Web Part appear in Outlook.
What’s the Story with OWA integration in SharePoint 2013?
I was somewhat surprised when SharePoint 2013 arrived and all the Outlook Web Access web parts were missing. Had this been an oversight by Microsoft and they would reappear again in a cumulative update for SharePoint? It appears not.
On further digging Microsoft actually dropped support for the OWA web parts (in SharePoint 2010) if your mail was hosted in Exchange Online (Office 365). From the Exchange Online Service Description document:
Exchange Online supports Outlook Web App Web Parts via the PageViewer control in Microsoft SharePoint Online and Microsoft SharePoint Server, or via manually configured URLs. Built-in SharePoint OWA Web Part controls will not work against Exchange Online
The statement above alludes to an alternate method using the Page Viewer control (which to be honest I’d prefer to the OWA web parts which didn’t have the full functionality of the OWA interface). The idea behind using the Page Viewer web part is that OWA is just a web interface to your Exchange account served up at known URLs. So just wrap these in a iframe (Page Viewer web part) and you will have your full OWA interface embedded inside a SharePoint page. For a step by step guide of how to setup the Page View control to connect to Exchange Online (OWA) take a look at this article by Jesper_Osgaard.
So fast forward to SharePoint 2013, can we still use the Page Viewer web part technique? My experience so far has yielded mixed results.
More often than not the Page Viewer technique gets tripped up with security issues. I think the underlying issue is that an Internet Explorer session cannot handle authenticating with multiple domains at the same time and it just so happens SharePoint Online and Exchange Online reside in different domains.
This isn’t to say it flat out doesn’t work. Here’s a screenshot to prove it (no smoke and mirrors or Photoshop involved I promise). But I just didn’t find it stable enough to recommend it as a viable solution.
On reflection it would seem that Microsoft wasn’t able to iron out the complexities of integrating OWA content and SharePoint content in the same Internet Explorer session. If they could, then surely that would have provided better integration for the native SharePoint Site Mailboxes that were introduced in SharePoint 2013 (Exchange 2013). When a SharePoint Site Mailbox is provisioned, a mailbox is created in Exchange (for the SharePoint site) and a link is placed on the left navigation of the SharePoint site. When you click on the link you don’t get the mailbox content embedded in the SharePoint page (as you might expect and have hoped for!). Instead it launches a new Internet Explorer window (new IE session that can authenticate with a different domain) and opens the OWA URL directly to the mailbox. There’s essential no integration with the SharePoint UI other than a URL link.
I’ve just been reading Tony Redmond’s article on one of the new features introduced in Exchange 2013 CU1. The ‘new’ public folders are now available within Outlook Web Access (OWA).
Here’s Tony’s full article and is well worth a read – Interesting approach to public folder support in Outlook Web App 2013
My main take aways are:
- New Exchange 2013 Public Folder’s are now accessible in OWA
- Unlike previous Public Folder (in Outlook and OWA) you don’t get the full hierarchy. Rather the user selects which folders (from anywhere within the hierarchy) to add to there Favorites.
I like the approach to not showing the full public folder hierarchy in the Outlook navigation. It’s an area we spent a great deal of time researching a designing when developing OnePlaceMail and exposing SharePoint locations within Outlook. We made the decision not to show the full SharePoint hierarchy directly within the Outlook navigation. I agree with the approach for the following reasons:
- The UI get’s unusable for large hierarchies
- Public folders can only have one set structure, but that’s not necessarily how every user sees it and often it exposes a lot of ‘clutter’ that the user is not interested in. Having the user select their favorite locations removes the clutter.
I would like to see the favorites area enhanced so that the user can categorise (or add levels of categories) to their favorites. This way the user can organise and structure favorites in a way that makes sense to them. This gets away from the issue of the old Public Folders where everyone must see the hierarchy in the same way. Allowing users to make up their own hierarchy of favorites allows them to organise the world how they see it and how it makes sense to them. I find this freedom is what keeps users happy and productive. Users are familiar with this in Outlook… take your common mail folder structure (i.e. inbox and subfolders the user creates). This works because users create mail folders ad-hoc and how it makes sense to them and what they are working on day to day. Allow them to categorise and move around shared Public Folders in the same way and everyone is happy. It’s an approach we’ve been using in OnePlaceMail to allow users to organise their SharePoint locations in Outlook for years, and it works.