Updating Checked Out Projects with JSOM

Another great thing to come out of Project Conf for me was the connections with people working on some of the same problems that I’ve faced, this is one of those; updating Projects which are checked out is not possible using the same old method that was used with the PSI! (Think about the problem this creates for PDP App Parts!)

Fortunately it is possible thanks to the following undocumented method discovered by Martin Petersen on his blog here:

Check it out, and thanks Martin for the solution!

Share and Enjoy !


AngularJS and SharePoint App Template

One of the best takeaways for me while working on my Exists App which is built on the MEAN stack was getting to learn AngularJS, better yet at SPConf it was immediately obvious that I’m not the only one who thinks that AngularJS and SharePoint Apps are a perfect fit!

If you don’t know much about AngularJS and want to learn how it relates to SharePoint then I’d highly recommend Jeremy Thake’s excellent session on the topic presented at SPConf where he gives a great introduction to what Angular can do and shows some great examples using SharePoint Apps.

AngularJS Visual Studio Project Template

I’ve been meaning to take this to the next level after toying with creating a basic template app building on the default VS SharePoint hosted App template and adding Angular and some example code in a well defined MVC style template. My intention is to convert this into a VS Template to work along side the default SharePoint App template, but for now I’ve just setup a GitHub repository with a sample (non-templated) project, which looks something like the following:


Have a look at the source on GitHub below.

SharePoint / AngularJS App Seed Project


This is a test project designed to be a seed project (or eventually a Visual Studio Template) to implement a SharePoint single-page App built using AngularJS with a heavy emphasis on MVC design patterns.

The project structure is built to be very familiar to any ASP.NET MVC developer, while providing a good starting point for a simple (or complex) SharePoint AngularJS based App.

Initial version notes

  • VS2013 SharePoint Hosted App Project Template
  • NUGET AngularJS-Core package
  • Folder structure as per ASP.NET MVC pattern (/Controllers, /Models, /Views, etc)
  • Sample Model, View and Controller including directive and services to recreate the “‘Hello ‘ + user.get_title()” default template functionality.

Feedback Please!

I’m very keen for any feedback on this so either post below or even on GitHub, in particular my choice of using Directives vs Views or Slices or Includes is somewhat arbitrary. Although it is largely based on my view that this SPA (Single Page App) should not need routes and such as I don’t want to think how that could work within an SPAppWeb.

Finally, I am by no means an Angular expert, in fact I’m brand new to it! So all suggestions on best-practices and relevant design patterns are more than welcome.

Share and Enjoy !


Project Conf 2014 Videos online, including my session!

Alex posted this morning with the news that the Project Conference 2014 session videos are now online: Project Conference Session videos now available on Channel 9

Of course including my session on Extending Project Online and on-premises with JavaScript Apps, see it here now if you missed it:


UPDATE 19/03: Just got the confirmation from Microsoft that my session PC403 was the highest rated of the conference! Awesome, thanks everyone for your evals and I’m very glad you enjoyed it!

Share and Enjoy !


SharePoint list conditional formatting with JSLink

This is one of the new features of SharePoint 2013 that I have been looking forward to trying out since I first read about it; as someone who has often uses JavaScript to enhance the usability of Project Server JSLink is a perfect feature to make these customisation’s simply and in a supportable way.

JSLink in Action


Check out my Exposure column on an otherwise default Project Site risk list! :)

JSLink enables the client-side rendering to be customised with just about any JavaScript or html changes that you think of, and better yet not only does it apply to views, but also New and Edit forms. For me that means I will probably never suggest InfoPath forms to a customer again!

Example Updating the Project Site Template

The screenshot above shows a simple example of a JSLink script configured on the project site out-of-the-box Risks list, to demonstrate how to do that quickly and easily against an existing list (or your Project Workspace Site template), first you need a bit of JavaScript:

JSLink script riskColor.js


CustomFormat.riskColor = function () {

    var riskFieldsContext = {};
    riskFieldsContext.Templates = {};
    riskFieldsContext.Templates.Fields = {
        "Exposure": { "View": CustomFormat.exposureColourTemplate }		


// This function provides the rendering logic for list view
CustomFormat.exposureColourTemplate = function(ctx) {

	var fieldValue = ctx.CurrentItem[ctx.CurrentFieldSchema.Name];

	if (parseFloat(fieldValue) > 7) {
		return "<span style='background-color : red'>&nbsp;&nbsp;&nbsp;&nbsp;</span> High (" + fieldValue + ")";
	else if (parseFloat(fieldValue) > 4) {
		return "<span style='background-color : gold'>&nbsp;&nbsp;&nbsp;&nbsp;</span> Medium (" + fieldValue + ")";
	else {
		return "<span style='background-color : green'>&nbsp;&nbsp;&nbsp;&nbsp;</span> Low (" + fieldValue + ")";

//CSR-override for MDS disabled site 

if (typeof _spPageContextInfo != "undefined" && _spPageContextInfo != null) {    		
	// CSR-override for MDS enabled site
	RegisterModuleInit(_spPageContextInfo.siteServerRelativeUrl + "/SiteCollectionDocuments/riskColor.js", CustomFormat.riskColor); 

In summary what is happening is the following:

On line 8 inside the CustomFormat.riskColor() function I define the field names which we want to customise and specify the formatting callback function for the type of customisation, in this case we are customising the “View” but we could use “DisplayForm”, “NewForm” or “EditForm” here also.

Two things to note here, firstly make sure you use the Internal Name of your field, so for instance if you created a custom column called “Risk Rating” then that would be “Risk_x0020_Rating”, secondly you can specify as many fields / columns by name here as you want each with a separate formatting function.

For more details on JSLink and all the other options available I’d recommend the following reading:

Next from line 19 to 26 in the CustomFormat.exposureColorTemplate() function I simply return our modified HTML based on the value of the field in question, in this example I’m comparing the number against three arbitrary values for High, Medium and Low, then returning a html string including a colour and some text to emphasize the value.

Finally and thanks to Wictor Wilen for his article on fixing the issues caused by MDS (SharePoint’s Minimal Download Strategy feature) I’m registering and then executing the script properly when called.

Registering the JSLink Script

Now that we have our script, we just need to register it in our site template, so to do so first save your script somewhere central in your site collection, I personally like Site Collection Documents under PWA, but wherever it is make sure everyone has access.

Secondly open your Risks list view and Edit Page from the SharePoint menu. With the page in Edit mode click the dropdown arrow for the Risks list web part and select Edit Web Part:



Now in the Web Part Properties expand Miscellaneous and locate the JS Link field:


The full path I’m using is:


This path also is referenced at the bottom of the script as _spPageContextInfo.siteServerRelativeUrl + “/SiteCollectionDocuments/riskColor.js” so make sure to set both correctly.

NOTE: I’ve found this step is critical, the ~sitecollection” token is REQUIRED in the web part misc properties! At least in my case I was able to consistently cause IE to throw script errors if I tried to use a relative path like /PWA/SiteCollectionDocuments/riskColor.js! It did work in Chrome so maybe it is something in IE? Either way you can replace that with ~site ,or ~layouts as required.

Finally save your webpart configuration and it should immediately work.

Final Words

A few things; firstly double check the URL using in the Web Part properties and make certain to specify the path correctly in both the script and the web part properties. If you noticed the views fail (I did many times) then double check the note above about the ~sitecollection token.

Secondly because we are using the out-of-the-box Risks list we must add this JS Link script reference to every view and web part display of our Risks list.

Thirdly clear your browser cache! This one had me stumped as it seemed like none of my changes were working when in fact the script changes were not being refreshed, I found disabling the cache (easy in F12 mode in Chrome) made testing this super easy.

Finally for a bunch of cool examples of JSLink in action don’t forget to have a look at:



I hope you find this useful.

Share and Enjoy !