Tweaking search results xslt to get document titles to open documents directly in browser instead of Office client

In a recent BI-project we needed lots of Excel files to be opened directly in the Excel web app also when found through search. All libraries were configured to open documents in the web browser, but even so search results always lists all document titles to open in Office clients.

In addition to displaying the document title, the author, description, ++, the default search results also display a separate 'View in browser' link for each document. So the logic was to get the functionality of this link to work for the item document titles instead.

This is quite easy to fix. You have to go into the XSLT file that controls how the search output is put together and do three minor changes. This is preferably done through SharePoint Designer.

I really, really advice you to not do these changes directly in the XSLT found in the web part properties of your search core results web part, but rather create your own XSLT file in SharePoint Designer and link this to your web part like described in Matthew McDermott's great blog.

In your copy of the original XSLT - do the following:

Here is the code that replaces the original div for srch-Title3:

<div class="srch-Title3">
<!-- call custom template to show link to doc that opens in browser-->
<span>
<xsl:call-template name="TitleOpensInBrowser">
<xsl:with-param name="browserlink" select="serverredirectedurl" />
<xsl:with-param name="currentId" select="$currentId" />
</xsl:call-template>
<xsl:text disable-output-escaping="yes">&amp;nbsp;</xsl:text>
</span>
</div>

Here is the custom template code that I've put right below the original ViewInBrowser template code:

<!-- Custom template to fetch doc title into link that opens in browser-->
<xsl:template name="TitleOpensInBrowser">
<xsl:param name="browserlink" />
<xsl:param name="currentId" />
<xsl:if test="string-length($browserlink) &gt; 0">
<span class="srch-urllink BISearchResultsUrlLink">
<a href="{$browserlink}" id="{concat($currentId,'_VBlink')}"><xsl:value-of select="title" /></a>
</span>
</xsl:if>
</xsl:template>

Also there is the param definition right at the top of the file:

<xsl:param name="TitleOpensInBrowser" />

This should do the trick. All items listed in your search results should now open in the web browser rather than in clients.

Beware! Business Data Connectivity is case sensitive for database field names

An unforeseen problem with a major impact was uncovered the other day. We have set up an external content type querying an SQL server database table. During a simple change to this table it was recreated with upper case field names, where it earlier had a mix of lower and upper.

This broke the External content types connected to this table. No external list data could be displayed, no external data columns in lists or libraries could be updated, and no actions (like view profile page) would function.

In SharePoint Designer configuration of operations (here the Read List Operation) it is obvious that the original configuration is not able to update with the 'new' column names. Both new and old formats are visible, but the original configurations are locked in and unavailable.


The only way to solve this problem was to recreate the table with the original column name formats. After doing so everything went back to normal.

Henning

No data displayed in external list due to wildcard filter lacking default value

I have been doing quite a bit of External Content Type work lately. One small thing that threw me off was that though everything seemed OK with the query and setup, my external list would not display data.

The simple solution in my case was that my Wildcard filter set up for the Read List Action needed a '%' in the Default value field under Filter Parameters Configuration. This for a SQL Server connection.

Group list items by first letter in item name in an A-Z list view

A really simple solution when a client needed an alphabetically displayed list of items. This was to be an A-Z list of useful tips for new employees.

I solved this by adding a calculated column to my list with the formula to extract just the first letter of each item's title like so: =LEFT(Title,LEN(1)).

Then I created a view with the Group By option set to my new column.

Simple but effective!

Deleting and recreating custom content type managed property killed search scope

Today I had a problem with one of our managed properties. I had created a custom managed property for displaying content type in the search XML and in the search refinement panel. I followed the description from Glyn Clough's Blog: http://www.glynblogs.com/2011/01/create-a-content-type-search-refinement-panel-in-sharepoint-2010.html when setting this up, and everything worked fine except for the problem that for some documents the mime type was listed as the content type instead of the content type's name.

See problem description on Technet forum: http://social.technet.microsoft.com/Forums/en-US/sharepointsearchprevious/thread/2e218709-1f1c-4da1-8bf6-2273b50ce37c/#5d495da5-bec2-4c8a-b960-059784ad5392

To try to fix this I deleted the custom content type managed property and recreated it exactly like I did the first time with same name, mapped it to the same crawled property ows_ContentType, and did a complete recrawl.

That solved the original problem, but now I found that a search scope that had used the original search scope in a rule (customContentType=someContentTypeName) no longer worked. No search results were returned by the scope, and when trying to edit the scope through Central Admin I got an error message stating: "The search service is currently offline...".

I ended up deleting the scope and recreating one exactly the same as the original.

SharePoint permission groups disappear when sites are deleted

This one really bugged us for a while. Seemingly at random some of our permission groups suddenly disappeared into thin air, leaving lots of users unable to access their SharePoint sites and content.

After doing some research we found that in every instance this was related to groups originally created for sites that were deleted some time ago. These permission groups at first seem to live on happily even after site deletion, but reusing these groups for new sites will come back and kick you hard.

The fact is that when you delete a site, the site lives on in the Recycle bin for 30 days (default setting), hence the site is not deleted but rather marked for deletion. And actually so are the permission groups originally created for the site during site creation. (These groups are only created if you do not opt for permission inheritance, of course.)

The big draw back is that there is no way to identify that these groups in fact are marked for deletion!

So, guess what happens then after the Recycle bin period is over and the cleanup job does what it's supposed to do? The site and permission groups are gone.

So. Best practice is to not keep using these permission groups, but rather always create new permission groups when creating new sites that need dedicated permissions. Or create permission groups outside of the site creation wizard and hook these up to your sites manually.

:-) Henning

Easy fix of slow webdav connections to SharePoint using IE on Windows 7

For some time I have been extremely annoyed by how slow it is to work with documents and files in SharePoint when I'm sitting outside of my office, logging into our VPN.

The problem is related to the Webdav (Web Document Authoring and Versioning) method that is being used, and apparently a setting in Internet Explorer related to this.

To fix the problem: in IE go into Tools -> Internet Options ->  Connections -> LAN Settings and uncheck the Automatically detect settings check box.

Instant fix!