Minifying JS – Skip removing line numbers?

I’m a big fan of App Insights, and I’m loving it’s increasing integration with Visual Studio. To me, it’s just great.

However, I did find myself laughing a bit at this. App Insights was recording JavaScript errors from a (third party’s) .JS file.


This is showing an error on Line 93. The thing is, the file has been minified – and all the code in the file is on line 93.

Hmm. All this would save is a couple of hundred bytes over the wire. I’m just not sure it’s worth it for most of the projects I work on. I think having the new-lines still in (albeit otherwise minified).

To be honest, we’d save more space by stripping out the 92 lines of Licensing information above the code. I’m not sure that that shouldn’t reside in a text file, and just have a comment referencing the licence information.

Minifying JS – Skip removing line numbers?

PreSaveAction() : Do stuff before form submit

I might be a little late to the party on this one, but I’ve just come across PreSaveAction() for SharePoint forms. This allows you to add a JavaScript function (called PreSaveAction) to a form, and it’ll get called before the form is submitted.

function PreSaveAction() {
	//Manipulate Fields before saving
	//Or perform custom validation
	//There's loads of uses, particularly if also using JQuery.
	return true; //Return false to cancel submit

Bizarrely, this has been in SharePoint since SP2007, yet somehow I’ve not come across it before. Clearly, it isn’t as powerful as Display Templates, but that’s a nice feature!

PreSaveAction() : Do stuff before form submit

Using JSOM to query SharePoint 2013 lists with Taxonomy Fields

So, I’d an interesting problem. I have a SharePoint 2013 list that uses a Managed Metadata (or ‘Taxonomy’) field. I need to, through the JavaScript Client Object Model, get all items that have a particular value or a child of that value on the taxonomy tree. As an example, here’s my taxonomy:termSet Sounds like it should be simple to query this, right? Well, not so much. Continue reading “Using JSOM to query SharePoint 2013 lists with Taxonomy Fields”

Using JSOM to query SharePoint 2013 lists with Taxonomy Fields

Looking up against Large Lists in Office 365

So, I had an issue that I’ve a customer who wanted to have some items look up against a large list. (In fact, it was a large document library). This large list had more than 5000 items. This is a little unfortunate, due to a painful and annoying quirk in SharePoint’s design. Continue reading “Looking up against Large Lists in Office 365”

Looking up against Large Lists in Office 365

Issues with getting the SP.ClientContext in SharePoint 2013

So, I’m migrating a solution from SP2010 to 2013. In the JavaScript for part of the solution, I use the JavaScript client-side object model (JSOM). This involves getting the current ClientContext for the site:

var clientContext = new SP.ClientContext.get_current();

Unfortunately, ClientContext was null, so I kept getting Null Reference exceptions.

“Weird”, I thought, “This worked in 2010”. Now, my solution has a very similar piece of code elsewhere in it, so I went and tested it – and it worked. Even weirder.

Next up, I tried using a SP.SOD.executeOrDelayUntilScriptLoaded() call around the code where I got the ClientContext. Surely it was just a matter of waiting for the JavaScript file ‘sp.js’ to load? Well, it never loaded. With these two lines…

SP.SOD.executeOrDelayUntilScriptLoaded(function () { alert('SP.Runtme.js Loaded'); }, 'SP.Runtime.js');
SP.SOD.executeOrDelayUntilScriptLoaded(function () { alert('SP.js Loaded'); }, 'SP.js');

…no alerts were shown. On the page that works, they both get shown nearly instantly.

Okay, so it’s not my code then, it’s that the JSOM isn’t initializing, but only on one particular page. That sucks. What can I do to initialise it? Well, I found this post describing the same problem, but for publishing pages. Mine isn’t – it’s an application page – but I suspected it might be the same issue. And I checked MSDN which describes initialising sp.js.

I added this line:

SP.SOD.executeFunc('sp.js', 'SP.ClientContext', function () { });

And my code began working again on this page. So it seems that for some pages in SharePoint 2013 the Client Object Model isn’t necessarily initialized.

Issues with getting the SP.ClientContext in SharePoint 2013

Check Permissions in JavaScript Client Object Model

I had a need to check the rights a user had on a particular item in SharePoint. Unfortunately, this had to be done entirely client side. Naturally, I turned to the client object model – but it took a little time to figure out.

I wanted to query for a particular item, some (though not all) of it’s properties, and I wanted to get it’s permissions. This post by Henrik Andersson gave me a good clue, though it didn’t explicitly mention getting the properties. To get the item, with it’s properties and it’s permissions:

//var clientContext = new SP.ClientContext(.... ;
clientContext.load(listItem, 'EffectiveBasePermissions', 'ID', 'Title', 'Owner', 'Active', 'Modified', 'Editor');
clientContext.executeQueryAsync(Function.createDelegate(this, this.OnItemQueryCompleted), Function.createDelegate(this, this.OnItemQueryFailed)); 

That performs the query to get the item and permissions – but how do you check them? Well, you need to to use the SP.ListItem.get_effectiveBasePermissions() method. (Note: there are SP.List.get_effectiveBasePermissions() and SP.Web.get_effectiveBasePermissions() methods too, for those tiers of the hierarchy).

function OnItemQueryCompleted(sender, args) {
	var perms = listItem.get_effectiveBasePermissions();

	if (perms.has(SP.PermissionKind.editListItems)) {
	      // ....

The permissions are retrieved into an SP.BasePermissions object, which has the .has() method that you can use to check the permissions (returns true if the user does have that permission). The Permissions mask is defined by the values in the SP.PermissionKind enumeration.

Check Permissions in JavaScript Client Object Model

Handle Exceptions in Client Object Model callbacks

A note to myself, of something I found on MSDN – for the ‘failed’ function on an asynchronous JavaScript call in the SharePoint Client Object Model:

function OnItemQueryFailed(sender, args)
   alert('Error:n' + args.get_message() + 'n' + args.get_stackTrace());

Note that these details are from the SP.ClientRequestFailedEventArgs class. There are other properties too.

Handle Exceptions in Client Object Model callbacks