So ran into a very weird issue. I had just finished patching our Dev and Test servers to the November 2017 CU. And after this occurred, any updates to solutions using JavaScript injection was not working. I’ll describe the problem in more detail here right away, but I want to make sure I give a call out to Trevor Seward. Trevor blogs from The SharePoint Farm and kudos goes to him for pointing me at the Blob Cache (but I am getting ahead of myself).

As with so many things I write about recently I had a need to do something different at my client site. This time I needed to fake a required field on a SharePoint list form. The reason behind it was we had customized the form and had some fields that were required in some cases, but not all. These fields could not be marked as required in the content type because then we would need to fill in default or bogus data into the fields and that wouldn’t look good so I decided to simply make the fields look exactly like a SharePoint required field without actually setting them up that way.

Fake a Required Field on a SharePoint List Form

This may already be documented somewhere, but I didn’t bother to look. I thought the solution I came up with is pretty quick and clean so I wanted to share it. I am basically just inserting the same <span> field that SharePoint does onto a label when the field is set as a required field. Using JQuery I get the <nobr> control and then insert the <span> after. Here’s the code to accomplish that:

So you just need to pass in the field name (display name, not the internal name) to the function. The code will find the corresponding <nobr> control on the form and update it to look like a required field. Kudos to a comment Marc Anderson made in a blog somewhere about accessing the <nobr> field. I would have done it a bit differently, but I liked the flow of the code in the comment he made.

Back in the SOM (Server Object Model) days it was pretty straight forward and well documented how to gather a user’s information from within a SharePoint form, or even go out and get it from SharePoint itself having just a single piece of information like email, login name or even just the user’s first and last name. While there are techniques to doing this from the client side using CSOM (Client Side Object Model) or REST APIs what if you didn’t need ALL the user’s information and just needed a few important parts of it. If the form you are working in has a people picker then you are all set. Today I am going to show you all about getting user data from People Picker with JavaScript.

My client has a sub site that has the sole purpose of housing their policy documents. They don’t want any other team site features on this site, just the library. The library contains a couple thousand documents all nicely categorized using metadata and organized by views. A recent request from them was to clear their site’s landing page of the default web parts and replace it with a list of the views. Each view in the list should link directly to that view in the library. To facilitate their request I decided to create a list of SharePoint views using REST services.

Choosing a Method

A number of methods are available for us to accomplish this:

Server-side Web Part: Bad. Don’t do this anymore. Stay as far away from server side code as much as possible. This is a discussion for another day and there are lots of resources out there outlining why we shouldn’t, but suffice to say, don’t do it.

CSOM Add-In: This is a strong possibility and one that is generally used, but we have developed a policy to avoid CSOM solutions because it still requires assemblies that have to be maintained

JSOM Add-In: This method is perfectly fine and something available to any SharePoint solution. It would suffice for my needs. I just chose a different method.

JavaScript and REST: I chose this method not because it is better than any of the others listed, but simply because my need was very basic and I didn’t need to build out a full solution to achieve my requirements. I could create my solution using a Content Editor Web Part (CEWP) and a single JavaScript file (well two because I used JQuery as well).

Create a List of SharePoint Views Using REST

The solution is pretty straight forward and uses very little custom code. The gist of the solution is removing all the web parts from the page. Adding the CEWP to the page. Uploading JQuery and my custom code file to Site Assets and referencing them from within the CEWP.

ListCollection REST Endpoint

To get the data from the list we need to make use of the ListCollection resource. A method within the resource allows us to access a list within by it’s name. So your REST call will have a base something like: “/<Site Name >/_api/web/lists/getbytitle(<List Title>)” So this gives us the list object. Instead of using the return data from SharePoint on this, we are able to tell the call that we want the views property within. So in the end our REST call is going to be http://teams.drevsp2013.com/bcs/_api/web/lists/getbytitle(‘Laptop Request Form’)/Views

Because it is so easy to work with we of course want to ensure we tell the service call we would like the results in JSON format. So we need to add an accept to the header “accept: application/json;odata=verbose”

Test with Fiddler

When checking out any REST endpoint I always use Fiddler. Two reasons:

Ensure I format my REST call correctly

Take a look at how the data is coming back so I know how to handle it in code

Setup and execute a Fiddler test as follows:

Taking a look at the JSON return, we see that we want to make use of the Title and the ServerRelativeUrl fields:

Create the REST Call

So building out this knowledge I wrote a little method called GetViewDetails. It accesses the REST endpoint and builds an associative array (I’ll explain why in a minute) to store the title and URL of the views.

Because the client only wanted their custom views I do not add All Documents or the internal hidden views to the array. Also note that I do not want this to be called asynchronously. Reason being is I am building out that array and I want to be able to return the values. If I don’t do this, it will return the data before the array is built.

Another requirement is to place all the views in alphabetical order. The REST service doesn’t do that by default. It actually returns the views in the order they were created. Enter the Associative Array. The associative array in Javascript is a Key\Value based array. So basically a dictionary or hashtable. By placing my data into this array I can sort the data on the key (view title) portion of the array. Before I show you that part, I am going to first add the necessary code to my CEWP as I make reference to some HTML in the web part within the next method.

After you add the CEWP, edit the source of the web parts content. Inside the HTML we are going to add the a div that our code can hook into and the script calls for the JS files.

So back to the JavaScript. The final piece to write is the portion that sorts the array and writes to the CEWP. The code to handle this:

In the code above, it sorts the key values of the array and places them into a new variable. We then use that order to loop through every item in the array and display them as needed. viewArray[sortedKeys[i]] is basically saying give me the value of the array when the key is equal to the value at ‘i’. We then attach to the un-ordered list created before the loop and for each entry in the array we add a list item to the un-ordered list.

So what we end up with is a list of links that correspond to each view and the url of the view.