In modern SharePoint libraries containing large collections of folders, it may be difficult to navigate your way around the folder hierarchy. The library loads batches of 30 folders as you scroll down the list, making it difficult to find a specific item. Would it not be great if you could easily filter the collection of folders? You can try to use search to find the desired item quicker, but if you have content with similar names, the suggested results are not always relevant.
I built a super simple SharePoint Framework list extension to filter folders and address this limitation. Check the video below to see the SharePoint folder filter extension in action.
SharePoint folder filter extension demo
I have deployed the extension to all sites in a client tenant. The feedback from end users was amazing!
I have extracted the functionality to explore folders from the solution and created a reusable control. The control was submitted to the PnP reusable controls project and will hopefully be available soon for anyone to use. Update: the FolderExplorer control is now available within the PnP repository on GitHub. The folder filter extension is very simple. It only needs to control the visibility of the side panel and redirect the user to the selected folder.
The extension is only visible for document libraries. It can be deployed globally to the tenant app catalog and be made available to all sites. Super simple and a great time saver for end users!
I am also planning to release the extension as a sample to the PnPextension samples repository. Update: a sample solution is now available within the PnP extensions samples repository on GitHub.
I have now also done a demo of the solution on the SharePoint developer community call
Some time ago, modern SharePoint sites received a new feature: modern Document Sets. In order to enable and use of this feature, “all” you have to do is enable the “Document Sets” feature under Site Collection Features. Then simply add the relevant content type to a library and you can start using them.
Simple right? Well…perhaps not so simple if you try to do this programmatically.
All we have to do through the UI is enable a feature, so we expect the same when done programmatically. And here we have multiple options: CSOM, PowerShell, or perhaps a (PnP) provisioning template. But this “not always” works, as reported on GitHub at least here and here. You can activate the feature and add the content type to the library, but you will get a file not found error for the document sets page (DocSetHome.aspx).
The first GitHub link above contains a workaround by Jlopean. In summary, if Custom Scripts are not enabled for the site collection, things just don’t work, so ensure that you activate Custom Scripts (on the site collection!) before activating the Document Sets feature and all works fine.
If you looking for different options to enable Custom Scripts, here is a great blog post by Antti K. Koskela.
You can configure default values on a SharePoint library (root folder) or library folder fields. For example, if you configure default values in a folder, documents added to that folder will automatically inherit those field values. This functionality is great when you have a project that heavily relies on metadata. Especially if metadata should be inherited through multiple levels of information.
Setting default field values via the SharePoint interface
You can configure default values via List Settings page under “Column default value settings” as per the following image
In the following example, I have configured my test list fields with default values. The “My Yes No field” has a default value of “Yes” at the list level. I then set a default value on the field to “No” for the “Folder 1” within the library. Folders configured with custom default values are displayed with a green icon in the settings page.
While this option to manually set the values is easy for an end user, it is not practical for complex scenarios where some automation may be required.
Setting default field values using PnP PowerShell
PnP PowerShell is always my go to option when I need to set configurations in some automated way. With a super simple Set-PnPDefaultColumnValues command, you can set the default values of any folder (including the root folder). It also makes it very easy to work with complex fields, like managed metadata or user fields. Just as an example, the following command (from the documentation) is to set a managed metadata field
While working on a client project, I faced an unexpected issue with default field values. Suddenly, the PnP PowerShell command to set the default values started throwing errors. The same piece of code that was working for some days to set multiple fields with default values. It was now returning a message stating that field XXXXXX was no longer available in the list.
I deleted a test field on the list and commented the line of the script where I was setting that field. I could see no reason for a script error relating to that field as the line was commented out. Checking the default fields configuration in the list settings page also din’t provide any useful information. Everything seemed to be working fine there. I then decided to find the place where the configuration is stored. It was likely the cause of my issues. After some search, I was quite surprised with what I found! The default field value configurations are stored as a client_LocationBasedDefaults.html file. Within the Forms folder of the document library where they are configured.
Why you may need to know this?
Back to using the sample list form the previous steps above, this can be easily checked using SharePoint Designer:
And for the custom test field that I have previously set, we can see that the HTML file contains a reference for it
In my case, the issues were down to the field that was removed from the list and had default values configured against some folders in the library. Deleting the field did not remove its reference from the client_LocationBasedDefaults.html file, and the PowerShell command was then failing when trying to set values on other fields for that folder. Deleting and recreating the folder also didn’t resolve the problem, so at the end it was just down to editing the HTML file and remove the references to the field previously deleted from the list. And “voila”, the PowerShell command was working again.
The latest release of PnP Reusable property pane controls (1.8.0) adds an additional property (webAbsoluteUrl) to the PropertyFieldListPicker control. It allows a target site to be specified for loading the lists.
Nowadays, the trend is to not use subsites as you can’t even create a modern SharePoint site as a sub-site. But in the past, the sub-site approach was commonly adopted by organizations when planning the Information Architecture of SharePoint sites. It was common to see global information stored within custom lists of the root web level, and surfaced on sub-sites.
A different approach was to use multiple site collections. Using one of the site collections as a central repository of information that would be consumed by the others.
If you have a project that follows one of the models described above, you were not able to use the PnP PropertyFieldListPicker control on your SharePoint Framework web parts to load data from a different site.
The PropertyFieldListPicker only had support to load the lists of the current site by default. It was not possible to specify a different target site.
The changes included in the 1.8.0 version introduce a new optional property (webAbsoluteUrl). It allows you to specify the web absolute URL of the target site to load the lists from.
This can be as simple as:
In this example we use the current web from the page context, which you really don’t need as that’s the default behavior, but you get the point.
One important thing to keep in mind is that you need to ensure that the users have permissions to access the list if the list is on a separate site/site collection.
Certificates are my “kryptonite”…hate the pain of going back to an old project and the first thing I have to deal with on the development environment are expired certificates.
SharePoint doesn’t like expired certificates as some features will not work as expected, so you’d better renew the certificates before doing anything else.
As a developer, this is not the type of task I do on my daily-basis, so every time I need to do it, I search for some guidance online and more than likely follow a guide on how to manually fix the problem.
Well, not anymore as this ends today thanks to my colleague Renato Gomes who introduced me to a fantastic tool that does all the work!