Author: Tarjei

I spent some time figuring this out at the Office365/SharePoint hackathon Arctic SharePoint Challenge so thought I would share, as I didn’t find anyone having done exactly this before.

My use case is that you have a web job in Azure that runs a PowerShell-script that polls a list in a SharePoint site in Office 365 looking for new items. After new items arre added, the job picks them up, creates site collections and applies pnp templates. This works well as a scheduled job, but it would be nicer if we could trigger the job automatically so we don’t have to wait for the scheduled start time. Of course, this approach should work for any type of web job, as long as it has the web hook endpoint.

It turns out that you can trigger the web job with Flow! The steps are as follows:

First you need the authentication tokens. Go to your App Service where you have the web job running, and click on Get publish profile

In that file, look for the publishprofile with publishMethod=”MSDeploy”. You need the userName and userPwd. E.g. in my case it was userName=”$ASPC2017″ userPWD=”LBxk5ttrvZTgAM7msxDGRZA0hy9Wws3gdNeuK33hacB52SSaAQRslmuzshzi”

Then you need the web hook url. You find that by selecting your web job and clicking on properties.

Go to Flow (e.g. via the list from where you want to trigger the web job) and create a new flow.

The first flow step is to add a SharePoint action for “when an item is created”, and give the url to your site and select the list you want to use as input.

The second flow step is to add an HTTP-action. Choose method POST, add the Uri to the web hook url. You don’t need to set headers and body. Choose Basic authentication and use the username and password from step 2.

The final flow should look like the following

That’s it! After an item is added to the list, your web job will hopefully trigger and start running. Hope this is helpful to someone.

I had a weird issue in my dev. env. where after I added a search results web part to a web part page I got a weird error in the browser console (itemPermMasks.customFromJson is undefined in sp.ribbon.js), and some functionality stopped working – to be precise:

Ribbon buttons stopped working

JavaScript code that relied on SP.SOD.* stopped working

Google didn’t really give me anything of value to resolve the issue, and I couldn’t understand how any of the JavaScript could cause the error either.

The solution – or rather, the workaround, turned out to be quite simple: Change the search results web part from rendering results synchroneously to asynchroneusly. This makes SharePoint load the scripts the web part depends on differently, and luckily this was enough to solve the issue in my case.

This will be a short and sweet post about how to update result types after display templates have changed. It’s a common scenario to update a display template with changes to managed properties. If your result types are using the display templates, you need to go to the result types and click update. Quite a cumbersome tasks if you are deploying changes to many display templates/result types.

In a recent project I’ve worked in we came up with the concept of Content Filters. In this post I will explain the general idea.

The rationale for creating the Content Filters is that to end users, configuring search results web parts can be hard. Even for SharePoint superusers and developers, you have to know a lot about how SharePoint search works, names of managed properties and fields etc. to be able to create advanced searches. We wanted to have a way for users to create powerful searches without having to configure search results web parts themselves.

We are storing queries into fields of the page, and then we have search results web parts provisioned on the page getting their queries from result sources which again are just picking up the query fields of the page. The result source query looks simply like this: {\Page.ContentFilterQuery1}

Since we have full control of the query, we can do cool things like letting the users write KQL, using fields on the page in different ways, include/exclude children terms for managed metadata searches, and more.

Technically, the content filters are being created using JavaScript logic, building an array of content filter configurations. The logic is backed by a configuration file with names of managed properties, field names etc. that is being used to render the content filter form fields and “backend”. The frontend is using angular.js. The queries and fields are being saved to the fields on the page, without the end user knowing about it.

A very valid alternative to using search result web parts to pick up the queries is to roll your own search results. The benefit of this is that you can use the configuration object itself to perform the queries, and grab the results using the REST api. It’s an overall simpler approach and has less moving parts. The drawback of the approach is that you have to roll your own display templates for the results. With the result web parts approach we get the advantage of the SharePoint search toolstack, with result items, query rules, display templates etc.

Problem: After web parts were added to pages, visitors (users with read-only access) saw the same content in all search web parts.

Solution: The solution to this problems was to set the QueryGroupName property to unique GUID’s for all web part instances.

In my current project (SharePoint 2013, publishing site) we have a few page layout with quite a lot of search results web parts, both Search Results Web Parts and Content by Query Web Parts. In our provisioning, we use the same web part definition to provision all the web parts of the same type. This was working fine to our knowledge for a long while, until we granted visitors access to the site.

From time to time we upgrade the pages by removing all web parts and adding the updated web parts from the page layout. After these upgrades, we discovered that visitors saw the same content in all web parts that used the same web part definition for provisioning. We could fix the problem by having an user with owner access visit the page – then something wired up correctly in the background that fixed the web parts for all users. Of course this was not really a fix: In our solution we have hundreds of pages, and we upgrade all pages roughly once a month (after each sprint).

The QueryGroupName property of the web part

We found that the culprit was the QueryGroupName property of the web parts, which is a “native” property of the search web parts themselves, but it is also a property in the DataProviderJSON property of the web part defintion.

We first attempted to use the value “Default” as the property value, which was suggested by a few. Unfortunately this didn’t work. We also tried to not set the property at all, but leave it out of the web part definition, in hope that SharePoint could set a value automatically. This didn’t work either.

In all the errors above, ULS reported with the following error message for visitors (full stack trace left out):

Setting new GUID’s with a token

The way we provision page layouts and web parts allows us to tap into the web part definitions before we add them to the page. We could therefore introduce a token “|NewGuid|” as the value of the QueryGroupName property, and on provisioning we replaced this token with a new, random GUID. This made all the web parts work again for all users.

Picture below: From the updated web part definition

We used this simple line of code to update the web part definition before we added it to the page: