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!
I was recently looking into the results returned by SharePoint 2013 under the scenario of alternate access mappings. Essentially this boils down to the same SharePoint content being available on different host URLs.
Here’s an example:
I can have a single site which I initially create on http://ourintranet, through the magic of alternate access mappings I can make the same SharePoint site also accessible on http://extranet.mycompany.com
SharePoint serves up exactly the same content irrespective of the URL host the user come in on. In the address bar of the users browser, the host portion of the URL remains constant as they navigate through the site e.g. if the user came in on http://extranet.mycompany.com they would not be switched over to the http://ourintranet host at any time.
These alternate access mappings carry across to search as well. The way this works is that the search processes will crawl the SharePoint site and index content based on one of the URLs (either http://ourintranet or http://extranet.mycompany.com, best practice is to use the access mapping of the default zone). When search results are requested the SharePoint server will find the matching results in it’s search index and then apply alternate access mappings to any of the URLs being returned so that even though the content was crawled and indexed with the URLs starting with http://ourintranet, if a user comes in on the http://extranet.mycompany.com URL and performs a search, then all search results will also use the http://extranet.mycompany.com access mapping.
Now to the issue with the ListUrl property being returned by search. This property simply misses the whole alternate access mapping transformation when the search results are returned and the value is read straight from the search index. Therefore the ListUrl property is fixed with the URL host that the search crawler is configured with. This means that when a user comes in on http://extranet.mycompany.com and performs a search, the ListUrl property will give back a result starting with http://ourintranet. Obviously this is not good and your users may not even have access to the content via the different access mapping.
Here’s an environment demonstrating the problem.
The initial site collection is created on http://vs-server38:83
The site collection is then extended (which creates the alternate access mapping) http://vs-server38:84
Through a browser we can now access the same site on http://vs-server38:83
or on http://vs-server38:84
The search content source is configured to crawl the content based on the default http://vs-server38:83 URL.
This screenshot performs exactly the same search query only it uses the alternate access mapping of http://vs-server38:84. This time the issue is evident. The Path, OriginalPath and SiteName properties all return URLs that have been mapped to the alternate access URL I used. Note the ListUrl property still returns the http://vs-server38:83 based URL.
Delving further, each managed search property has a property called UseAAMMapping that seems to be the flag that tells SharePoint that the property contains a URL and need to apply alternate access mapping transformation when results are returned. Looking at the UseAAMMapping property through PowerShell we can see that the ListUrl property does not have this flag set while the other URL based properties (that work correctly) do have this flag set.