Bits and pieces

In the last couple of blogs we looked at basics of PnP Modern Search Extensibility and how to add a custom layout , in this blog we will look at how to extend PnP Modern Search webparts by adding custom web components. A Web component is a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML elements that can be used in your templates to implement complex behaviors. In this solution we use them here as  "wrappers"  for React components to be able to use them with Handlebars. In the previous blog, we used <pnp-collapsible> built in web component, here is the complete list of built-in web components provided by PnP, <pnp-iconfile> <pnp-documentcard> <pnp-filepreview> <pnp-icon> <pnp-panel> <pnp-collapsible> <pnp-img> <pnp-breadcrumb> In our example, we want to make changes to the People layout, we want to make it clickable and show pronouns beside the person’s name. We also want to de...

In the last blog  we were looking at the basics of PnP Modern Search Extensibility, what we can customize  and how to create a the library component. In this blog, we will explore how to add custom layouts using extensibility.  Right now, PnP Modern Search Results webpart provides you with these 5 layouts, Details List, Cards, Slider, List and People, which should be sufficient for simpler scanarios. In addition to that, it also allows you to customize the layout by editing the handlebar template using “edit result template” option under Custom layout, or you can create a custom handlebar file, upload it on SharePoint and then add its location in “ Use an external template layout” option. For example, you are setting up a Search Results page for showing projects. If you use the the default List layout, then the results would end up looking like in the image below, it shows page title, author, date modified, project summary and then what all tags the project has been...

What is it? The PnP Modern Search solution includes a set of open-source web parts for SharePoint Online that allow for a highly customizable search experience. These web parts can be configured to create tailored search results pages, with features like dynamic filters, sorting, and pagination. PNP Modern Search Extensibility refers to the ability to customize and extend the PnP Modern Search webparts. This is achieved through various tools, components, and practices provided by the PnP community. Why do we need it? Before PnP Modern Search Extensibility was introduced, to achieve the desired changes to the search results, a lot of developers would make changes to the PnP Modern Search solution itself, which would result in the solution being detached from the community version, and if there were major releases done on the community version which were now desired on the cloned version, there would be no way to just deploy the new community package without losing the customizatio...

I have always been fascinated by different authentication mechanisms that Microsoft provides and recently when a colleague of mine was working on a custom connector, I got to assist her with setting up On-behalf of Flow authentication. Custom Connectors are kind of actions provided by 3rd parties that users can use in Microsoft Flows. First of all you need to create a Web API, that will perform the action when someone uses the custom connector. You will need to host this Web API on Azure and create an AAD application that will register the Web API. You will also need create an AAD app that will register the custom connector. You will also need to establish communication between Web API AAD app and Custom Connector AAD App. Steps for this can be found here,  https://hiralpatel-sharepointdevelope.blogspot.com/2019/03/steps-to-create-custom-connector-for.html Basically, here, our client is our custom connector, which communicates with the AAD app hosted on azure to acquire a ac...

The client's requirement was to use a Shared Mailbox which will have multiple alias and according to the alias determine a library on SharePoint and store the email in that library. Now, from flow's action "when a new email arrives in a shared mailbox" you can't determine the email sent to which alias. This is where use of exchange transport rules came to my mind. So, what I did, I created an exchange transport rule for every alias, which will prefix name of the alias to the subject line of the email and then while processing the email in flow I, through some string operations got the name of alias out of the subject line. In the image below, the email was originally sent to alias HRJobs@xyz.com, but when it got to Flow you can see that in the To address, the value is mycompanyjobs@xyz.com, which is address of the Shared mailbox. In the subject line you would see how HRJobs is prefixed. Well, this is it until next time! Thanks for reading.

This came as a client requirement and made me scratch my head for days. The requirement was that the client would perform a search, apply refiners, change sort order etc. and we needed to export the result that is being displayed to the user. In rest api, we have an end point for search which accepts QueryText and Refiners and returns search result which we can write to the CSV file. But the real challenge is to transform all the operations that are done by the user on the search page to the acceptable parameters of rest api. As you might have noticed when you perform the search, whatever operation you perform, the parameters are added to the query string and a request is sent to the server. So we can read the parameters from the query string and create rest api specific parameters.  So we will be converting https://*****.sharepoint.com/sites/Search/Pages/search.aspx?k=test#Default={"k":"test","r":[{"n":"RefinableString15",...