Sharepoint: Change Sort Order Within A Group In A Grouped View

Sharepoint’s built in grouped view is a quick, useful way to make long lists more user friendly. It allows you to group items together based on a common value in a field and provides a “toggle” option to open or collapse each group. But once you’ve added the grouped view, you may find sorting your list is not as straightforward as you’d expect.

Adding a custom sort option to the groups (to manually control the order in which they appear) is simple enough. You can add a “sort” field – so non technical users can simply enter a number to determine the order. But what if you also want to sort items WITHIN EACH GROUP? You would think you’d just add a second sort option – so:

  • First sort by your group sort field
  • Then sort by your sort within a group field

But if you do that, the second, “sort within a group” option is ignored. When it didn’t work for me, I quickly googled for “sort within a group when using a SP  grouped view” but got no useful results. So I tried reversing the sort options – in other words, first sort by the Sort Within Group field, and THEN by the Group Order field….and even though this seemed highly illogical to me, it worked.

So once again, Sharepoint provides a useful feature made less useful by the unintuitive interface. Anyway, that’s how to sort the sorts when using a grouped view!

This should work for all versions of Sharepoint, but I’ve only tested it in Sharepoint Online.

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.



Add Custom Search to a Sharepoint Online 2013 Blog Site

Planet Microsoft.
Sometimes I think Microsoft must be living on a different planet. They provide a useful blog site template with a lot of built in functionality and enough flexibility to allow it to be used in a variety of ways – not just as a blog. But the out of the box search function uses a results page located in the dreaded _layouts directory that prohibits any customization. That’s okay if you’re not customizing your blog site, but I find it hard to believe anyone would consider the dreadful out of the box blog styling acceptable for a serious enterprise intranet or public site.

Searching for the right search.

So if you customize your blog site’s look, how do you fix the search results page so it looks like it belongs to the same site and doesn’t revert to the appallingly bland default /_layouts/15/osssearchresults.aspx page?

After a lot of googling and a series of frustrating and failed attempts to play with master pages and page layouts, I hit upon a very easy solution. Instead of trying to force the site’s framework onto the search results page, insert the search into the site. Here’s how I did it:

How to

  • First I made a copy of the post.aspx page.
  • I renamed it search-results.aspx. (You can either delete or hide the default web parts on the page).
  • I opened the page in edit mode and inserted a search results web part.
  • I then opened the site settings > search > search settings.
  • And specified the page results should be sent to.



Refine your search.
That alone connects your site’s search box to the results web part on the designated page. Which is pretty cool.It does however return everything in the site collection index – a lot of which may be irrelevant. My thinking is if someone is searching a blog they probably only want to see relevant posts in that blog. So I refined the results as follows:

Open the new search results page and edit the results web part’s properties.
Click change query.
Change the “select a query”, “restrict by app” and “restrict by content type” settings according to the image below.


That will only return relevant posts. Of course you can vary that schema depending on your own desired results. And the end”result” is this – regular post page on the left and search results page on the right:



So there you go – a quick and easy way to use built in functionality to do what Microsoft should have already done for you! Hard to believe how simple this really is – and harder to believe why Msft doesn’t do a better job of documenting simple answers like this to common questions.


Visit my forum » if you have any questions. For development work, you can contact me here ». And if you think this would be useful to others, feel free to share it by clicking one of the share buttons up top!

Add scripts/iframes to Sharepoint 2013 blog posts.

If you add code for an iframe or a script to a Sharepoint blog post, you’ll be greeted with an annoying alert that warns you that: “some of your html may have been modified”. In effect, filters in the text editor strip out your code as a result of one of Microsoft’s odder design decisions: to allow iframe and script codes in a page but strip them out from the rich text “body” field in their blog post template. This inconsistency is annoying andnot getting any attention from Microsoft, so we need to workaround it.One option to get around this odd restriction is to add another field to the post list view web part that will dodge the rich text field filters, and render iframes and scripts right below the body field. This article will show you how to do that in 4 steps:

1/ Add an html field to the post list
2/ Rig it so it renders as html not text
3/ Add the field to the list’s views
4/ Add a simple script via a jslink file so it shows up in the post.

Add an html field to the post list
Navigate to your blog post list’s settings and add a single line text column called”html” to the list.

Rig it so it renders as html not text
Add a calculated column with this formula:=html.
Name the field”Calc” – if you use a different name make sure you update the field name in the jslink file referenced below.
Important:SELECT “NUMBER” AS THE OUTPUT. This little trick ensures the code you enter in the html field will render as code and not plain text. Keep in mind the character limit of a single line text field is 255, so your code will have to be below that!

Add the field to the list’s views
Adding a field to the post list view and then updating the view on the post.aspx page will break the connections and scripts that make the blog work. So you will have to open the post.aspx page in Sharepoint Designer, click into the appropriate list view web part and use the”add fields” tool in the ribbon.

Because of a bug and Msft’s lack of quality control, the list view tools may not be visible, in which case use this trick:
Right click the list view web part.
Click”tag properties” which will open the properties dialog and then OK.

Now the tools should show up, and you can add the”Calc” field to the list view web part. You will need to repeat this for the other blog pages if you want your html to show on them: date.aspx, default.aspx, category.aspx.

NOTE: If your html field returns “undefined”, go back to post.aspx in SPD and make sure the field ref name of your field (“html”) is included in the query of the list view web part.

After editing these pages, you’ll notice the”blog tools” web part now displays an error and the page may not look right. This is another bug in SP that you can easily repair by adding the blog tools web part again and deleting the original.

Add a simple script via a jslink file so it shows up in the post.
If you’re not familiar with jslink, you can download the file below and upload it to a root library, such as site assets.

To connect it to your list view web parts, open up the web part properties and under”Miscellaneous>jslink” add the path to the file formatted with the appropriate site token. For example, for, use ~sitecollection/siteassets/blog-html.js. The token MUST be used for jslink to work.

Download jslink file here

Add your code
To test, edit a post and add a simple iframe code to the new”html” field. As mentioned, you cannot exceed 255 characters. I wrapped the html field in a span with a class of “post-html”, so you can adjust the styling as needed.


Visit my forum » if you have any questions. For development work, you can contact me here ». And if you think this would be useful to others, feel free to share it by clicking one of the share buttons up top!

Microsoft Announces “Plans” To Replace Office 365 Public Web Sites

Speculation about replacement offerings for the Sharepoint Online public web site feature in Office 365 abounded after Msft announced its demise, first reported here ». Azure? Orchard? Sway?None of the above. In a very quiet update to the original kb that revealed the discontinuation of public sites, Msft has made it clear they are basically going to do nothing….well, nothing that you couldn’t do already.

They claim they are “partnering” with Wix and GoDaddy but this is a “partnership” that doesn’t benefit 365 users at all. The public site will not be integrated in anyway with O365 or come with any subscription discounts or special pricing. No data migration or site conversion will be offered that isn’t already provided by their new partners.
So basically the “partnership” claim is just a way of saving face. They are reducing the feature set of O365 with no compensatory price reduction and not subsidizing the new “service” in any way. In other words they are cutting their public site customers loose. Nice. One has to wonder if THEY are in fact getting any affiliate compensation for pushing so many customers to Wix and GoDaddy……
It’s well known Msft hasn’t been able to figure out a way to make money from hosting public web sites. And they certainly can’t be blamed for trying to refocus their resources on Office 365’s many strengths – which the public site offering couldn’t be counted among. But here was a chance to get creative, be imaginative and drum up a little customer love. Essentially they are making loyal customers pay AGAIN for their poorly thought out venture in the public site space.
Here’s that venture’s rather depressing timeline:

  • 2005-06: They initially attracted a large following by enticing small businesses with a “forever free” domain and hosting offerin the OLSB service.
  • c 2008: Realizing that was a bad decision, they started charging for domains
  • 2010-12: Next they started charging for hosting and forced customers to manually rebuild their sites in O365.
  • 2015: Now they are telling users to go elsewhere…..The fact that this announcement was buried in a kb update rather than given a little more prominence is a clear indication thet Msft knows this will not go over well. They should be ashamed of themselves…. .