As everyone knows by now, Microsoft is pushing all development out to the client-side. But most of the time, I find customers who desire customization want a user experience that is somewhat tailored to the current user. Like managers should see one thing when they log in, but regular users should see something else. That means that on the client-side, I need to be able to distinguish managers from other users. That’s normally done by assigning the users to groups. But in large organizations, that usually means Active Directory groups, which are then added to SharePoint groups. This leads to a problem, because from the client-side, there is no way to determine if the user has membership in a SharePoint group to which they’ve been added indirectly (i.e. through membership in an Active Directory group).
JavaScript
Using a Polyfill Service with SharePoint
If you’ve read many of my previous posts, you have probably seen me use polyfills (i.e. CRUD Operations for SharePoint Docs Using Fetch and REST), to patch older browsers with modern functionality like fetch. I generally download the polyfill, upload it to SharePoint, and load it on the page as a user custom action. But there is another way to load polyfills, which is generally called a polyfill service. The idea is that you load the polyfill from some external service, which detects your current browser, and loads just enough polyfill to patch your current browser up to some level of specification compatibility (usually like ES5, but you can also generally ask for specific functionality, like fetch and/or Promise). There are some unique problems with loading this kind of polyfill in SharePoint, mostly due to limitations in user custom actions. In this post I’m going to talk about how to load such a polyfill in SharePoint, but first lets talk a little more about polyfill services in general.
An Entity Editor Display Template, Advanced Client Side Rendering
Ever had a list in SharePoint with a choice field that allowed multiple selections (i.e. checkboxes)? And with many things to choose from? See the picture below. In this particular case, you’d need to scroll down a page or two to see all of the choices. I’ve seen a lot of people try to solve this problem by making the choices wrap around inline instead of one per line, which is a fine solution if your choices are relatively small strings and there is a small enough number of them. But what if there are over 100 choices, and some of them are pretty big strings? That’s the problem I’m trying to solve with this Entity Editor Display Template.
Star Ratings Display Template, Advanced CSR
In this post, I’m going to do a CSR field rendering template for a star ratings field. It’s just what it sounds like, give the user an opportunity to rate something with 0 to 5 stars, by clicking into an image of 5 stars. Under the hood it will just be a numeric field, but as much as possible I’d like the user to never see the number. Anywhere the field appears, they should see an image with the appropriate number of gold stars.
Parameter Aliases in SharePoint REST
This relatively brief post will explain what a Parameter Alias is in OData. They’re used in examples throughout the SharePoint REST API Documentation, and there is a brief description of them (see references), but they are not very well explained. The basic syntax looks like:
Loading JavaScript or CSS on Every Page in a Site using JSOM (UserCustomActions)
A common question in SharePoint forums is how do I load SuchAndSuch.js on every page in the site collection (ok, let’s be honest, it’s usually how to I load jQuery on every page). This is pretty easy to do using the SharePoint client object model and setting something called UserCustomActions. I showed using this utility page in my Accordion View, Custom List View CSR Template. In this post, I’m going to show what’s going on behind the curtains in that utility page. It will be an ASPX page (really just a text file) that you can drop in any SharePoint document library and click on to start immediately configuring UserCustomActions at either the site or the web level. It has no dependencies. It is a self contained page with only HTML and pure JavaScript.
CSR on Steroids and the Amazing Technicolor Text Boxes, or CSR by Type
First things first, I want to apologize, because what I’m going to build in this post is pretty hideous. I’m going to introduce the concept of hooking up SharePoint CSR by type, rather than by internal field name (as most examples show). In this post, I’m going to show how to do CSR by Type, meaning override all fields of a given SPFieldType.
By way of background, yesterday I was trying to override the Client-side Rendering (CSR) of a Url field to allow it to take non-standard protocols like notes://. I didn’t feel like creating a site column so I applied it to the OOB site column called Url. So I setup my overrides like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | // override the render for the field called Url? var overrides = { Templates: { Url: { NewForm: editOverride, EditForm: editOverride, DisplayForm: displayOverride, View: displayOverride, } }, // insert the css OnPostRender: postRender, }; // register the template overrides, and to keep it simple, ignoring MDS SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrides); |
Here I’m overriding the rendering for the field called Url in all forms and views, right? Not so fast sparky! This worked a little too well. My override was getting called for other fields of type SPFieldUrl on the page that weren’t named Url. Ugh! Stepping through clienttemplates.js in the debugger, it quickly became apparent what was going on. In the fields object, you can specify CSR by internal field name, like I’ve been doing in previous posts in this series, but you can also specify CSR by type of field (using the client-side field type, so for instance Text for SPFieldText). This replaces the default rendering for all fields of that type.
That’s actually pretty cool, but the problem with it is that if you have a field whose internal name is the same as a field type, there is no way for you to override just that field. Bad Microsoft, programmer no donut! The rest of this post is going to be a quick demo I put together to demonstrate this functionality. I haven’t seen anything in the documentation for CSR, or any examples, that explain this functionality. Of course, the documentation for CSR is pretty thin.
Managing Role Assignments/Permissions with SharePoint REST Part2
In my last post I described many of the REST endpoints available in SharePoint to manage role assignments. In this post, I will provide a concrete example of using these endpoints in a provisioning-like scenario. I say provision-like because real provisioning scenarios tend to be very specific and one-offs (i.e. I need 7 sites, each with 5 lists and 3 groups, based on a naming convention by organization, and these permissions, and blah and blah and blah). Such specific requirements can’t be written into a one size fits all solution, so I’m just going to mimic them by creating a whole bunch of role assignments, and then deal with some of the issues of initiating a bunch of ajax calls in a short period of time.
Managing Role Assignments/Permissions with SharePoint REST
To assign permissions in SharePoint, you make one or more role assignments, which requires three things:
- Some kind of handle for a securable object. That’s basically a site, list, library, folder, document, or item.
- The principal id for something to which roles can be assigned. That’s either an Active Directory user or security group, or a SharePoint group.
- The id of a role definition. Like ‘Full Control’ or ‘Edit’ or ‘Contribute’. This is basically a named collection of granular permissions that are defined at the site collection root and can be assigned to a securable object in that site collection.
In this post, I’m going to explain the REST service calls required in order to make role assignments to SharePoint securable objects. I will show the calls using jQuery’s ajax (because I’m working through them in the console and the console won’t resolve promises). I’ll follow up with a post with some demo code pulling it all together and probably using fetch.
A Fetch-based CORS Wrapper for SharePoint REST
In this post, I’m going to create a better CORS Wrapper for SharePoint REST operations, and demonstrate using it for CRUD operations on a Picture library. First, I want to remove the dependency of jQuery, using fetch instead. As I covered in a previous post, Ugly SPA Revisited using Fetch and REST, fetch is new enough and implementations are spotty enough, even in evergreen browsers, that I will need to polyfill fetch and ES6 promise in order to support a reasonable cross-section of browsers.
By implementing the full range of CRUD operations on document libraries, we’ll have an opportunity to see if there are other issues that need to be addressed in our CORS Wrapper. My last post really only did one simple REST operation across CORS boundaries.