Use the 'a=' url parameter when passing 'hidden' search strings to a SharePoint search page

On several sites we have links that trigger searches by passing the term GUID to the search page through the 'k=' parameter, as you can see from the URL. This is a neat way of showing all items tagged by a certain term. In fact you can use this method to pass any search string to a search page, not just metadata guids (example: ...resultpage.aspx?k=author:someone).

So this actually works great, but for one thing. I would like to not display the rather cryptic search string in the search box. In addition to the core search results web part on a search page the search box web part also picks up the value passed into the page by the 'k=' parameter, and displays it as the current searched for string.

One solution is to deselect the 'Display submitted search' option in the search box web part properties configuration, but I choose not to because I would like normal search strings entered in the box by the users to display.

After doing a lot of searching for alternatives one of my local MVPs, Mikael Svenson, came up with the easy solution: use the 'a=' parameter instead of 'k='. Has exactly the same effect on filtering the core search results web part, but without displaying the search string in the search box.

One important thing to note is that the core search results web part needs an additional value. Just passing in a value for the 'a=' parameter will return nothing. In my case I added a simple additional query in the 'Append text to query' field in the core results edit web part properties. I used 'IsDocument=1' because I want the search page to list all documents within the defined search scope to be listed if no other search string is given by the user.

How to set hyperlink url and display name in Sharepoint Designer workflow

A Hyperlink field is made up of two separate parts, the clickable display name and the actual URL. In SharePoint Designer Workflow there is only one field to set for both values.

I was creating a custom 'My favorites'  list when this problem came up. I wanted to create a simple workflow in a document library where users could opt to create links to certain documents in the favorites list by running the workflow for each of these items.

The central part of the document library workflow is of course the create item action. The action is simply set to create an item in the favorites list that sets the item's URL field. I created a workflow variable where I define the string that will hold both the link's display name and URL. Thus the first action of the workflow is to update the variable.

In the string builder dialog simply put together: [%Current Item:URL%], [%Current Item:Name%]. The URL and display name is thus separated by a comma and space. Both of these are important.

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.