Thursday, January 24, 2019

A no-nonsense solution to implement cascading dropdowns using PowerApps as a custom form in SharePoint

Search for “powerapps cascading dropdowns sharepoint” on the interwebs and you will find a bunch of ways to get this to work, but I dare to say that the solution I propose is by far the easiest and most elegant. And a big thank you to my colleague Thomas who helped along with this one.

My sample is super easy. I have three lists, Countries, Cities and Customers. Cities has a lookup to Countries, and Customers has a lookup to both Countries and Cities.

image

By default the input form looks like the image below, where all cities are shown regardless of the selected country. But this is easily fixed.

image

Monday, January 7, 2019

Introducing the SharePoint REST API v2.0

image

For as long as REST has been supported in SharePoint the endpoint programmers have used is http://server/site/_api/ or https://contoso.sharepoint.com/_api for those of us who left on-premises years and years ago.

Now Microsoft has given us a v2 endpoint for the REST API. This has sort slipped under the radar, but I’m happy to announce that it’s there, it’s supported, and you can use it!

But wait, what is this v2 API, and why should I care or use it?

Friday, January 4, 2019

Eh??? Ok? Be aware of a modern change which can impact your classical way of displaying search results

image
My colleague Tarald recently discovered that when looking at the managed property CreatedBy for modern pages where you have filled in the author byline, it will show the primary e-mail address, display name, and claims token for that user (and the claim includes the user principle name).

foo.bar@contoso.com | Bar, Foo | 693A30232E667C6D656D626572736869707C666F6F2E62617240636F6E746F736F2E636F6D i:0#.f|membership|foo.bar@contoso.com

Maybe not a big deal, but since forever, this managed property has contained only the display name of the user, nothing else. I’m not saying it’s a bad thing to give all the data as that disambiguates people with the same name, but what’s bad is changing default behavior which has been consistent for a long time.

The culprit to it all is that Microsoft has decided to map the crawled property ows_q_USER_AuthorByline as the first property when populating the managed property CreatedBy. The same mapping is done to the AuthorOWSUSER managed property, which is ok, as this property always had all data included.

image

The best option in my opinion is for Microsoft to remove this mapping, and create a new AuthorByLine managed property instead. That’s the way SharePoint developers have been taught to do when introducing new values. You can also change the mapping yourself, but that might mess up some oob web parts.