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:


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.