Posts

Showing posts from 2017

Server Resource Quota in SharePoint Online

Image
Q. What does the Server Resource Quota setting do in SharePoint Online?
A. Right now, nothing. Nothing at all.















Earlier this week I was talking to an IT Manager who's been troubleshooting some performance issues on a SharePoint Online site collection. As part of his investigation, he raised the issue with Microsoft Support.

Among other things, the support engineer advised him to increase the Server Resource Quota for the site collection.

Microsoft Support should really know better. For the avoidance of doubt, the Server Resource Quota existed solely to limit the amount of server resources that any sandboxed solutions running in the site collection can consume over a 24-hour period. As code-based sandboxed solutions have been blocked entirely in SharePoint Online from July 2016, this setting now does absolutely nothing at all. I'd assume that in time it will disappear from the admin center UI.

Changes to link sharing defaults in SharePoint Online

Image
Just a quick note (followed by a quick rant) on a recent change to sharing in Office 365 (both SharePoint Online and OneDrive for Business) that's caused us a couple of issues over the last week.

The issue came to light when a team member tried to get the URL of a document in a SharePoint Online document library. You'll be aware that you can't just right-click and copy the URL in SharePoint - instead you can either right-click the document and then click Get a link on the context menu, or you can select the document and click Get a link on the toolbar:





















My user - who has permissions to edit the document in question - was presented with a nasty error message:















The reason for this is that when you get a link in SharePoint Online (or OneDrive for Business), it now defaults to creating a link that grants anonymous access to the document. If you've locked down anonymous sharing on your site collection, the user will get an error message instead.

If you want to change this beh…

Avoiding deployment validation errors with SPFx packages

Image
Just a quick note on a gotcha I came across when deploying an SPFx package to the App Catalog:

In the package-solution.json file, make sure your solution name doesn't use dot notation (or for my American friends, doesn't contain periods). This appears to prevent SharePoint from recognising your .sppkg file as a valid app package.



I started with a package-solution.json file that resembled the following - a nicely-qualified solution name, or so I thought:

{
    "solution": {
        "name": "Chorus.TiledNewsPart",
        "id": "83a75dd2-26d3-4235-b4ba-d0d4a8b19443",
        "version": "1.0.0.2"
    },
    "paths": {
        "zippedPackage": "solution/chorustilednewspart.sppkg"
    }
}

When I dropped the package into the App Catalog, I saw the following:










As you can see, things don't look good:

A bunch of fields (Title, Product ID, Metadata Language) haven't been populated.The Valid Ap…

Creating Services with SPFx

Update 21st April 2017: While the SPFx service model behaves as expected on the SharePoint workbench, I've had less success when the web parts that consume the service are packaged and deployed via the App Catalog. When the script files and the service package are served locally, the service class is instantiated only once. When the script files are served from a CDN, the service class is instantiated multiple times: once by each web part that consumes the service. The call to ServiceKey.create is also executed once for each web part that consumes the service - which effectively means that the page-level ServiceScope hosts multiple instances of the same service, each registered against a different ServiceKey object. I can only assume that this is due to a nuance of the bundling process that I'm missing. The result of this is that the SPFx service model isn't currently all that useful to me for sharing data between web parts. As a workaround, I've reverted to storing da…

SharePoint Framework POST requests: watch out for OData version incompatibility

This week I've been building a SharePoint Framework web part that queries a Pages list, amongst other things. For reasons that I won't go into, I need to do this by sending a CAML query to the server. The usual way to do this is to send a POST request to the getitems REST endpoint:

[Web URL]/_api/web/lists/getbyid('[List GUID]')/getitems

Where the body of the request contains your CAML query:

'query': {
   '__metadata': {'type': 'SP.CamlQuery' },
   'ViewXml': '<View><Query><Where>...'
}

To do this the SPFx way, we leave jQuery.ajax behind and use the SPHttpClient.post method. However, when I did this, the server returned an HTTP 400/Bad Request response with the error message:

The property '__metadata' does not exist on type 'SP.CamlQuery'. Make sure to only use property names that are defined by the type.

After a bit of trial and error in Fiddler, I found the problem:

The SPHttpClient class ap…

Getting or Setting Multi-Value Metadata Fields with the REST API

Image
A couple of years ago, I published a series of posts on getting and setting taxonomy field values in SharePoint workflows by using the REST API in custom workflow activities. These custom activities have served me well, but they've always been unable to work with multi-value taxonomy fields. It's time to fix that.

Background As you probably already know, when you add a taxonomy field to a SharePoint list, SharePoint adds a corresponding hidden note field. For example, if you add a taxonomy field named Colours, you actually get:

A taxonomy field named Colours. Depending on whether the column allows the user to select multiple terms, the field accepts values of type SP.Taxonomy.TaxonomyFieldValue or Collection(SP.Taxonomy.TaxonomyFieldValue).A hidden note field, probably named Colours_0.  The hidden note field stores the contents of the field in a term string format. In a single-value taxonomy field, the format looks like this:
Red|87999a76-e3cb-433c-96ad-c6fe354db476
And in a mult…