Add a clickable, “friendly” title to your Sharepoint Online 2013 documents – AND open them in the browser!

17_6_21_weird_file_names_revision_3.docx -SAY WHAT??

Let’s face it, file names are often not pretty. The underscores, hyphens  and other meta data elements in company naming conventions along with individual quirks and naming habits, can lead to some pretty unfriendly looking links in your document libraries.  You’d think the creators of Office would know better, but Microsoft doesn’t provide a simple way to replace those odd looking links with more descriptive text that would help end users find the files they need.

Rendering html in a calculated field – RIP 6/13/17

The easiest solution was always to use the trusty calculated field to replace the file name with something else that humans might understand. But since Microsoft announced on June 13th they removed the ability to render calculated fields as html (on June 13th  – supposedly to terminate this 10 year old “security risk”  – nice!) – come September (if you got the extension) this will no longer be an option.

Jslink saves the day

Fortunately for now at least, we have jslink – which allows you to rewrite how a web part is rendered. You can google up many expert tutorials on how to use jslink – I’m just concerned here with the specific syntax needed to replace a file name with user friendly text.

To start, add a single line text field to your library to contain the text you want to use, naming it something really original, for example: “Title”.  Overwrite the “Item” ctx element with the following:

overrideCtx.Templates.Item = CustomItem;
function CustomItem(ctx) {
// Build a list item entry for every item in the list.
var ret = “<div class=’link’><a href='<domain/library>” + ctx.CurrentItem.FileLeafRef + “‘>” + ctx.CurrentItem.Title +  “</a> </div>”;
return ret;

In this example, “ctx.CurrentItem.FileLeafRef” provides the file name and “ctx.CurrentItem.Title” provides your user friendly title.

Add “open in browser” functionality

The only issue with this approach is it will force users to download the file, and won’t open it in the browser, regardless of the settings you’ve configured for the library (another piece of Microsoft brilliance!)

If you want users to be able to open files in the browser, you’ll need to include one of the url query parameters that enforce that behavior in your script. I found this link format works best:

<domain/library>/_layouts/15/WopiFrame.aspx?sourcedoc=%7B<item guid here>

To derive the internal field name for the item guid, I turned to this handy list of internal field names and found it was “UniqueId”.

So now to display a user friendly file name AND open files in the browser, update the jslink script to:

overrideCtx.Templates.Item = CustomItem;
function CustomItem(ctx) {
// Build a list item entry for every item in the list.
var ret = “<div class=’link’><a href='<domain/library>/_layouts/15/WopiFrame.aspx?sourcedoc=” + ctx.CurrentItem.UniqueId + “‘>” + ctx.CurrentItem.Title + “</a> </div>”;
return ret;


More fields, no problem

Follow the same syntax above to add any number of other fields to your list view – just make sure they’re included in the view you’re using. And that’s how you turn “17_6_21_weird_file_names_revision_3.docxinto “Weird File Names June 2017”




Create a custom view and rss feed of a Sharepoint Online 2013 survey

A unique feature of the “survey” app in Sharepoint Online is the built in branching logic which makes it a useful choice for questionnaires etc. But if you want to customize the results view that users can see, you’ll find that Microsoft, in their infinite wisdom, has intentionally hidden the standard “create a view” option in the survey (aka list) settings.

The create view url

Fortunately, it’s only “hidden” and can easily be accessed if you know the correct url. To find that url, open up a regular list, click the “list” tab and “list settings” in the ribbon, and the “create view” link. The url format is:

https://<domain>/_layouts/15/ViewType.aspx?List=%7GUID%7D&Source=URL TO REDIRECT TO

So the magic page address is “ViewType.aspx” and if you combine that with your survey’s GUID , you can create your own views.

To do that, navigate to “site contents” and click the tile for your survey. Under the “settings” link, click “survey settings”.  Note the url and replace “survedit.aspx” with “ViewType.aspx” and open the page. You’ll now see the standard list view creation page and can begin creating your own custom view.

Your custom view won’t appear as a choice in the view section of the settings page (which is hidden),  but it will appear in the view choices link up at the top right of any view page.

My rss feed is empty?

Another annoying omission in survey lists is the availability of the rss feed url. Normally, if rss is enabled in the list settings, you’d click the rss icon in the settings ribbon to see the feed and grab the feed url. Not so in a survey list, where the ribbon doesn’t appear and the rss icon under “Actions” opens an empty feed. It looks to me like the url generated there is missing the view guid and so is empty, and most likely a bug.

If you want the correct feed url,  open the appropriate view page, edit it, open the web part properties and click “edit current view”. To the right of the “web address of this view” url, you’ll see a tiny rss icon which, if clicked, will reveal the correct feed from which you can get the feed url. In this case the page name is “listfeed.aspx”, so you can also manually combine that with the list and view GUID’s to get the feed url:

/_layouts/15/listfeed.aspx?List=LIST GUID&View=VIEW GUID

The last survey question about Sharepoint surveys

The only remaining mystery about survey lists in Sharepoint Online is what benefit Microsoft sees in hiding the ability to create views and get rss urls….feel free to comment if you want to tackle that one!

Hide header row in “custom” style list views, retain it in “default” style – Sharepoint Online (2010-13)

The “style” option in Sharepoint list view settings allows you to apply a different template to your list view. But when you use any style other than “default”, the header row just doesn’t belong. With the “boxed” or “newsletter” style, the headings are misplaced and look like a mistake. If you don’t want to mess with the xsl underlying these templates, many Sharepoint sme’s recommend hiding the header row by applying this simple css rule:


It’s a good practice to add that to a site stylesheet so you don’t have to insert it on every page where you want to remove the header. What the Sharepoint experts I’ve seen writing about this don’t tell you, is that rule will also get applied to the default style, where you probably want to keep it.

Luckily, a quick browser inspection reveals that among the morass of code used to generate list view web parts, the default style has a class not used on the other list view styles. So with one more line of css added to a site stylesheet, you can hide the header where it’s not needed and retain it where it is:


Using a workflow to get email addresses from a people field in Sharepoint Online (2013)

Limitations of the people picker field

The people picker field in a Sharepoint list is a useful tool: it allows users to sign up for say, a membership list,  by simply starting to type their last name and selecting from a drop down of “suggestions” supplied by the the user profile service. The people field contains an array of user information including profile picture, email address, department etc. but you have to choose which option you want to display when you create the field. A common problem is that once you’ve defined the type of output for the field  – “name with picture and details”, for example – you can’t then use the field to also display another value, such as the user’s email address or employee id.

So if a client asks for additional information to display in a separate field after you’ve created the column, it can’t be done – without adding another people picker column which is not efficient or practical. It’s a frustrating design because Sharepoint is querying all the data, but you can only include one format of that data in a view.

The challenge – populate a field based on another field’s value

I recently bumped into this limitation after creating a simple app that allows users to send each other ecards. The app comprises a list, a selection of different card designs and a workflow that sends out the ecards. The workflow gets the email addresses of the recipient and the sender (from the “created by” field) fine, but now I was being asked to add an option that would automatically email the recipient’s manager, if the sender requested it.

So essentially what I was tasked with was figuring out how to dynamically populate a field based on a value in another field. In Sharepoint, that’s the stuff of nightmares!

The solution – workflow logic

For this app, I was focused on getting the manager’s email address using the “recipient” people picker field, but the underlying process can be adapted to display any additional, available data from any people field in the list – employee id, picture, department etc. So for instance if you want to show a user’s picture and details in one field and email address in another, you can do it with this process using only one people picker field as a data source.

For the manager details,  Msft provides an action in Sharepoint 2010 workflows that can look up a user’s manager – the “Find manager of …” action. The logic needed for this part of the workflow then was:

  • If the sender selects the “email manager” box
  • Look up the manager of the recipient and return it as a variable
  • Update the “manager” field with manager’s email address
  • Wait for that update to happen, then…continue the workflow.

Assuming the workflow does its job, I’d then have all the email addresses needed to include the recipient, sender  – and manager (if applicable) in the “to” and “cc” boxes within the email editor.

The solution – step by step

So to get started, I added to the list 2 new columns: a boolean yes/no field (to trigger the manager look up action) and a people picker field to house the workflow generated manager’s email address. (I hid the manager field so it wouldn’t show up in the form view by activating content type options on the list).

The existing workflow was adapted to include the above logic, as you can see here:

Workflow steps

  • Condition – if current item field = value
  • Action – Find manager of current item field (recipient) and create a variable
  • Action – update “manager” field with variable (formatted as string)
  • Action – wait for manager field to update
  • Then continue the workflow – adding conditions/actions based on card design selected and populating the email address fields, email body etc.


As a rule I dislike editing existing workflows because they never seem to work after you tinker with them. In general, if you delete something, make sure you don’t leave any extra lines between the workflow’s elements. And make sure conditional rules don’t bleed into each other!

it’s also worth noting the data formatting of the values returned has to be right. There are little drop downs that show the options when configuring this which are easily missed.  The manager variable should be returned as a string to ensure all the people details are available in the manager field, but when you add the manager field to the email it should (obviously) be returned as an email address.




Fixing the date archive page in a Sharepoint Online 2013 blog site

Categories, date archive pages not filtering posts?

It’s a common problem: the category and date archive pages  on a Sharepoint blog site stop working and users see all posts instead of a filtered view.  It’s easy enough to insert a new “blog tools” web part (which a well known bug breaks if you edit the category.aspx or date.aspx pages). If that doesn’t do it, there are several articles about how to fix the category page – like this one:

The fix involves restoring a CAML query that Sharepoint mysteriously strips out. The same approach applies to the date archive page  but the specific query is different and hasn’t received as much attention, so I thought it worthwhile spelling out what needs to be done.

Restoring the missing CAML query

In Sharepoint Designer, open your blog site and navigate to the date.aspx page in the posts list.

It’s always a good idea to make a quick copy of ANYTHING you edit in Sharepoint, before diving in. Then, edit it in advanced mode.

Do a search for “<Query><OrderBy><FieldRef Name=”PublishedDate” ” to locate the section of the posts list view web part that needs to be edited.

After the closing orderby tag  “</OrderBy>”, add the following CAML query:

<Where><And><And><Geq><FieldRef Name=”PublishedDate”/><Value Type=”DateTime” IncludeTimeValue=”TRUE” StorageTZ=”TRUE”><GetVar Scope=”Request” Name=”StartDateTime”/></Value></Geq><Lt><FieldRef Name=”PublishedDate”/><Value Type=”DateTime” IncludeTimeValue=”TRUE” StorageTZ=”TRUE”><GetVar Scope=”Request” Name=”EndDateTime”/></Value></Lt></And><Eq><FieldRef Name=”_ModerationStatus”/><Value Type=”ModStat”>0</Value></Eq></And></Where>

It should look like this:

Click to enlarge »

Since this is generic code with no guid’s, and doesn’t appear to have changed much over the years, it’s “safe” to use and  should work in any blog site in any version of SP.

Now, save the page, open it in the browser, restore the “blog tools” web part which will inevitably be broken and check that your filtering is working again.

The straw that broke the CAML’s back

WHY the CAML query gets stripped out remains a mystery and is another example of the questionable development standards in Sharepoint, the platform’s fragility and Msft’s lack of focus on the user experience. But at least now there’s a quick and easy fix.