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.
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.
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.