Showing posts from 2017

Targeted Links in a Modern SharePoint UI

Recently I was advising a client on building out intranet-style content on SharePoint Online. I walked them through communication sites and modern team sites, demonstrated the mobile-friendly responsive rendering, the ease of editing, and so on. Then came the killer question: "how do I target my navigation links to different users?" This might well be on Microsoft's product backlog... but at the time of writing, there's no support for audience targeting with communication sites or modern team sites. So how do we use targeted navigation without losing the benefits of the modern UI? After a bit of trial-and-error we came up with a working solution using modern pages within classic SharePoint sites. There are quite a few gotchas, hence this post. Step 1: Create a suitable site Create or locate a classic SharePoint site (e.g. using the  Team Site - SharePoint Online configuration template). Gotcha #1: Don't use a publishing site template, or you won't be c

Automating Navigation Inheritance for SharePoint Sites

Automating site creation processes with SharePoint workflow has cropped up a lot in this blog over the years. The latest battle has been getting newly-created subsites to inherit the top link navigation bar from the site collection root. In summary... At the time of writing, you can't switch on navigation inheritance using the REST API. I've tried, exhaustively. Google agrees. You can switch it on using client-side code (managed client or JavaScript)... but that's no use for applications such as workflow where you're limited to code-free solutions. However...  if you can do it with client-side code, you can do it by calling the client.svc service with an XML body. It's ugly but effective. Your web service call should look something like this: Endpoint: {Web URL}/_vti_bin/client.svc/ProcessQuery HTTP method: POST Headers: Content-Type: text/xml Body: <Request AddExpandoFieldTypeSuffix="true" SchemaVersion="" Libr

Versioning SharePoint Framework Packages

TL;DR: Package versioning in SPFx web parts is confusing. Your sites will notify you that an upgrade is available, but will automatically use the latest version of your code regardless. Package versioning behaviour in the SharePoint Framework is currently a little idiosyncratic, and it recently caused us a few headaches. It seems that from a versioning perspective SharePoint (incorrectly) expects the SPFx packages to behave like SharePoint Add-ins. In this post I'll run through some of the issues we encountered and how we worked through it. Context You can version an SPFx package in three places: The SharePoint package manifest , in the package-solution.json file. The component manifests , in one or more .manifest.json files. The NPM package manifest , in the package.json file. In this post we're looking at the SharePoint package manifest (package-solution.json) as this is the version number that SharePoint reads and propagates when you deploy a package to the App

Server Resource Quota in SharePoint Online

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

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: Couldn't create the link - Attempted to perform an unauthorized operation 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 lock

Avoiding deployment validation errors with SPFx packages

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": ""     },     "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

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

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

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