SharePoint 2013 and AngularJS perform CRUD operations in multiple site collections with REST

SharePoint 2013 and AngularJS-performing CRUD operations in multiple site collections with REST

Overview:

This post covers a specific scenario with SharePoint 2013 and AngularJS (or other javascript framework) to host HTML and JavaScript in one site collection that create/update SharePoint list items that reside in a completely different site collection, and doing so without using SharePoint Hosted Apps.

If you are using AngularJS/SharePoint 2013 in a project that requires both querying AND updating data stored in lists that reside in a separate site collection than where the AngularJS app files are hosted than you may want to read on.

Issue:

The app files are stored at the root of the web application while the data is distributed to separate site collections and team sites for each organization and individual teams. This structure provides a mechanism to distribute the data surfaced in the AngularJS UI using SharePoint to provide the necessary security trimming of the data at each level of the organization.  Using SharePoint for the backend data and security and structuring the information architecture in this manner was designed to eliminate the need to manage user permissions as part of the custom application.

In SharePoint 2013 hosted apps the ability to query and update list items dispersed among multiple site collections is provided by scoping the SharePoint app to tenant and using the SP.RequestExecutor to make the REST calls (I covered in a recent post)

In this particular application however the decision was made not to go with a SharePoint hosted app until a solution could be developed to safely remove the app id from the URL.

Recently,  in fact just last week we ran into a blocking issue performing updates to lists that reside in a different site collection than were the AngularJS app files reside.  Once we rolled out the new site collection/team site structure the development team reported that the REST calls to perform updates to the list items were now all of a sudden returning an error. Curiously these identical REST calls functioned as expected when the data resided in the same site collection as the REST code and although errors now returned when performing updates the code was able to query the data in the separate site collection as expected.

Error:

The REST call to the _api/ContextInfo was failing with the message “the Method was not allowed and that it was using a GET but required a POST”  This was odd since the code was in fact using a POST, not a GET.

Solution:

When I first dug into the issue myself it occurred to me that maybe the form digest issue was the culprit. I reviewed the code being used to make the REST calls to update the data and it all appeared fine-very similar to documented examples from Jeremy Thake, Andrew Connell, and others.   Wictor Wilen has a well documented fix for the form digest issue on his blog but after reviewing against our existing code did not see any substantial difference that would explain why our code was failing.  The code in our specific application is slightly different since it uses promises but had similar characteristics to examples from other sources.

However I did notice our code was hard-coded to the root URL so I tried changing the call to use the URL to the site where the data resided rather than the root site collection.

Example:

FROM:

$.ajax({
    url: "/_api/contextinfo",
    method: "POST",
    headers: { "Accept": "application/json; odata=verbose"},
    success: function (data) {
        $('#__REQUESTDIGEST').val(data.d.GetContextWebInformation.FormDigestValue)
    },
    error: function (data, errorCode, errorMessage) {
        alert(errorMessage)
    }
});
TO:
$.ajax({
    url: /org/team/subteam/_api/contextinfo",
    method: "POST",
    headers: { "Accept": "application/json; odata=verbose"},
    success: function (data) {
        $('#__REQUESTDIGEST').val(data.d.GetContextWebInformation.FormDigestValue)
    },
    error: function (data, errorCode, errorMessage) {
        alert(errorMessage)
    }
});
Unfortunately this did not resolve the issue entirely-I did additional research along with trial and error to determine the root cause of the error.  Finally thought to read the comments on Wictor Wilens post on the form digest issue and there the solution presented itself in one of the comments-one line from a comment stood out that if you use Type: Post  rather than Method: Post the call will give you the $(‘#__REQUESTDIGEST’).val() rather than the object.  Sure enough, turned my chair around and asked the developer to give it a try.  IT WORKED!  So simple but seemed like a needle in the haystack on a day where this one issue was holding up deploying the app for our customer to test.  Seems obvious looking back, but like my grandma said hindsight is 20/20.
Root cause:
SharePoint requires the form digest for creating and updating items in separate site collections but not for querying items and our code was not accounting for providing the correct URL for the source data and was using method: POST rather than TYPE: POST when attempting to access the #_REQUESTDIGEST.val required for the post to execute successfully.

Resolution:
When creating or updating list items from javascript executed in a separate site collection than the SharePoint list resides AND you are not using a SharePoint Hosted App and SP.RequestExecutor ensure you set your REST call to use type: “POST” rather than method: POST AND  pass in the URL to the site where the data actually resides for the _api/contextinfo.

Updated example:

$.ajax({
    url: /org/team/subteam/_api/contextinfo",
    type: "POST",
    headers: { "Accept": "application/json; odata=verbose"},
    success: function (data) {
        $('#__REQUESTDIGEST').val(data.d.GetContextWebInformation.FormDigestValue)
    },
    error: function (data, errorCode, errorMessage) {
        alert(errorMessage)
    }
});
Guess its a good idea to read blog comments:)

Also, big props to Wictor Wilen for sharing great info and also to whoever posted this insightful comment on his blog that saved the day:

“it’s a great post, but one issue is coming with “method: ‘POST’ – which is it is throwing “The HTTP method ‘GET’ cannot be used to access the resource ‘GetContextWebInformation’. The operation type of the resource is specified as ‘Default’. Please use correct HTTP method to invoke the resource”.
 If we’ll use “type – ‘Post” rather than “method – ‘Post’, it will give you the $(‘#__REQUESTDIGEST’).val(). :)”

http://www.wictorwilen.se/sharepoint-2013-how-to-refresh-the-request-digest-value-in-javascript

Rod Stagg

 

TIP using SP.RequestExecutor to access data in SharePoint 2013 hosted apps with AngularJS cross domain

Background: In my current project developing a SharePoint 2013 hosted app where all the UI is developed in AngularJS presentation framework while using SharePoint host site collection and subsites for storing data in lists, security, version control, etc.  Convinced this is the best way to develop great UI in SharePoint after seeing the results of using AngularJS presentation framework for UI and SharePoint hosted app for the data.  There are a couple custom WCF services and also Node.js in the mix as well-very cool and the client very happy with the speed and responsiveness of the single page app.

In the process though, ran into a couple interesting aspects of accessing data from lists stored in both the SharePoint host site collection and subsites.  The few examples I found are from Jeremy Thake here and Andrew Connell here and recommend both since they are excellent.  But overall the web is a little sparse working with data in the host site collection/subsites using the SharePoint cross domain access via SP.RequestExecutor. The one I started from is a decent post on http://msdn.microsoft.com/en-us/library/office/fp179927%28v=office.15%29.aspx#SP15Accessdatafromremoteapp_Hostweb but there are few details when working with AngularJS routes had to work out in addition so sharing for those working on similar projects.

Tips for avoiding issues accessing SharePoint lists in the host site collection/subsites web in a SharePoint 2013 hosted app and angularJS routing.

TIP 1: Avoiding SP not defined issue: ensure the appurl passed to SP.RequestExector cross domain does not contain unacceptable characters in the url obtained from the querystring parameters.

One example being the angularJS “#/” that can get appended to the SPAppWebURL in the querystring

One slightly frustrating issue easy to miss was with the appweburl used by SP.RequestExecutor. Watch out for the SPAppWebURL obtained from the querystring when using SharePoint cross-domain access and AngularJS routes. If SP.Requestor sees the “#/” you may get an error displayed in FireFox as “SP not defined“.

Example URL:

http://app-33fd23755c4644.apps.smartek21:20982/AmazonRodUpdates/Pages/app.html?SPHostUrl=http%3A%2F%2Fwin-6viq5heh7nd%3A20982&SPLanguage=en-US&SPClientTag=0&SPProductNumber=15.0.4569.1000&SPAppWebUrl=http%3A%2F%2Fapp-33fd23755c4644.apps.smartek21%3A20982%2FAmazonRodUpdates#/goals

Removing the “#/” from the appweburl is one way to resolve this issue.

appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”)).split(“#/”)[0];

//Get the URI decoded URLs.
hostweburl = decodeURIComponent(getQueryStringParameter(“SPHostUrl”));
//appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”));
appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”)).split(“#/”)[0];
var scriptbase = hostweburl + “/_layouts/15/”;

// Load the js files and continue to the successHandler

$.getScript(scriptbase + “SP.RequestExecutor.js”, loadUser);

function getQueryStringParameter(paramToRetrieve) {
var params =
document.URL.split(“?”)[1].split(“&”);
var strParams = “”;
for (var i = 0; i < params.length; i = i + 1) {
var singleParam = params[i].split(“=”);
if (singleParam[0] == paramToRetrieve)
return singleParam[1];
}
}

TIP 2: Avoiding scoping issues: ensure you set the proper scope for accessing SharePoint list data in subsites and/or cross site collections

When accessing lists stored in subsites in the host web set the scope to tenant in AppManifest/xml

<AppPermissionRequests>
<AppPermissionRequest Scope=”http://sharepoint/content/tenant&#8221; Right=”Write” />
<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web/list&#8221; Right=”Write” />
<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web&#8221; Right=”Write” />
</AppPermissionRequests>
Example AngularJS routing used:

var goalsApp = angular.module(‘goalsApp’, ['ui.bootstrap', 'ui.bootstrap.tpls', 'ui.router', 'ngGrid']);

goalsApp.config(function ($stateProvider, $urlRouterProvider, $httpProvider) {

$urlRouterProvider.otherwise(‘/goals’);

$stateProvider

// HOME STATES AND NESTED VIEWS

.state(‘dashboard’, {
url: ‘/dashboard’,
templateUrl: ‘../apps/partials/dashboard/dashboard.html’,
controller: ‘dashboard’,
controllerAs: ‘vm’
})
//nest projects on dashboard page
.state(‘dashboard.projects’, {
url: ‘/projects’,
templateUrl: ‘../apps/partials/projects/projects.html’,
controller: ‘projects’,
controllerAs: ‘vm’
})

// customers
.state(‘customers’, {
url: ‘/customers’,
templateUrl: ‘../apps/partials/customers/customers.html’,
controller: ‘customers’,
controllerAs: ‘vm’
})

// goals
.state(‘goals’, {
url: ‘/goals’,
templateUrl: ‘../apps/partials/goals/goals.html’,
controller: ‘businessreview’,
controllerAs: ‘vm’
})

});

AngularJS and SharePoint 2013 together-loving it!

Rod Stagg

http://rstagg.com

SharePoint 2013-Printing List Item Forms using jQuery and CSS

UPDATE 4/26/2014:

Have heard from a lot of people who are having some challenges putting all the pieces of this solution together, particularly the calculated field for the print icon.  Providing detailed instructions and a screenshot to get started.

Start from a new team site:

  • Create a new subsite from the Collaboration template using the Team Site template.
  • Use listprint for the site name and URL.
  • Create a new picture library named “Images1″
  • Upload the print icon to the picture library.  Download image here
  • Create a custom list named “List”
  • Add the following columns to the list:
  • Column name: Printed | Column Type: Text | Default value: No
  • Column name: Print Item | Column Type: Calculated Column  Download calculated field formula example here

Capture

 

 

 

 

 

 

 

 

  • Add a new item to the list.
  • Click on the new item link.
  • From the standard DispForm.aspx page select Settings > Edit page
  • Add a new Script Editor web-part to the page (located in the Media and Content Category in web part gallery)
  • Set the Script Editor web-part properties zone index to 2 from the web part settings, layout section.
  • Select Edit Snippet in the Script Editor webpart and paste in the following jQuery/CSS-Download script here
  • Update the siteUrl variable in the jquery to use your site URL as required.
  • Select Page, Stop Editing from the SharePoint ribbon.
  • From site contents select “List”
  • Select a link to one of the two items in the list, select the Print button.
  • From site contents select “List” and notice the first item in the list has been updated to reflect Printed=Yes.

That’s it to getting started.

I have paired down the solution to get you started and make additional customizations specific to your requirements for example the listitemid that gets updated is hard-coded to the first item id since my solution depends on a SharePoint Designer workflow which I did not package up in the wsp (Coming soon) This can be easily updated to use your own jQuery inside the script editor web-part to obtain from the querystring on dispform.aspx or from a custom field that is populated from a SPD workflow when the item gets created.  You can easily create a list on any existing SharePoint 2013 or Office 365 SharePoint site providing you update the script and calculated columns to reflect the correct URLs and image source in the jQuery embedded in the Script Editor web-part and also the Print Item calculated field formula.

Thanks, Rod.

Added Functionality verses standard list item form:

* Add a print button to a SharePoint list item form.

* Displays a print icon linked to the custom print preview form.

* Tracks which list items were printed by the user. Works on both Office 365 and on-premises versions of SharePoint 2013.

printfeature

Capture

 

 

 

 

 

 

Solution Details

Solution designed to meet a requirement from a customer to allow users to easily print a list item from the primary SharePoint list view page in a layout that maximized the allowable printing real-estate while also removing most of the SharePoint toolbars etc. from the printed page.  Also, the customer requested that we track which items had been printed since this solution was part of a larger scheduling solution for SharePoint.   Since the customer is hosting their SharePoint on Office 365 in the cloud we opted to use jQuery and CSS directly on the list item form.  For layout we opted to use a custom list item display form and modify the XSL although this is not necessary to support the jQuery and CSS for printing the list item.

Steps: 

  • jQuery added to list item form with embedded jQuery and CSS overrides in a script editor web-part.
  • Calculated field with a print icon and link to list item form added to the list view.
  • Optional: Customized list item form layout using XSL.

Next Steps:

Package as a SharePoint app that can be added to any site.
Create a custom print template.
Incorporate PDF.

Summary

Even in 2013 it is sometimes necessary to print to paper.  With SharePoint being used more and more for scheduling and tracking systems, workflows, and calendaring the ability to print a SharePoint list item when necessary is an added benefit.  With the advent of CSOM and JSOM developers are increasingly taking advantage of jQuery, HTML, and CSS to tackle specific gaps in the OOB SharePoint features and particularly in the O365 cloud version.

Have fun!

Rod.

Have you Seen This? Javascript API for accessing SharePoint and Office Live web services

javascript api for SharePoint and Office Live web services-

This works pretty well and have found it useful to save me time from building the xml packets myself.  Doesn’t have all the SP services-the profile service added recently.  The list service pretty well done.  This guy wrote a tool to generate all this-would be cool to have that tool.

http://darrenjohnstone.net/2008/07/22/a-cross-browser-javascript-api-for-the-sharepoint-and-office-live-web-services/