Set-PnPDefaultColumnValues with "-Folder" not working

[TimTimBS]

Hi,

I'm trying to use the Set-PnPDefaultColumnValues command to set a default value for a managed metadata column on multiple folders.

For some reason this command doesn't work for me at all. I've read that the command has a bug if the folder hast special characters. So I created a new folder named "Test" and even renamed my productionfolder.
For testing purposes I've also just tried to set an single line of text default value.

It just doesn't work

I always get the "Set-PnPDefaultColumnValues : Error applying default column values" Error

I already tried different combinations:
Set-PnPDefaultColumnValues -List Dokumente -Field Status_x0020_Unterschrift -Folder "/Test" -Value "Test"
Set-PnPDefaultColumnValues -List Dokumente -Field Status_x0020_Unterschrift -Folder "Test" -Value "Test"
Set-PnPDefaultColumnValues -List "Freigegebene Dokumente" -Field Status_x0020_Unterschrift -Folder "/Test" -Value "Test"

Here are the some values I've set manually to see what I should use as the folder and field param:

I'm working on the PnP.PowerShell Version 1.2.0.

Has this command still the same bug it has back in 2016/2017?

Thanks for your feedback 🛸🏴‍☠️

[erwinvanhunen]

If there was a bug before, then it's likely that bug transferred with the cmdlet to the new module. Most of the cmdlets are simply copies of the ones in the legacy library. We wil have a look at it.

[erwinvanhunen]

Right, in order to set the default column value to a term, you have to execute the cmdlet as follows:

Set-PnPDefaultColumnValues -List [listname] -Folder -Field [fieldname] -Folder "Test" -Value "TERMGROUP|TERMSET|TERM"

So if you have a term called "Internal" which is located in a termset called "Scopes" which resides in the termgroup "Corporate" the value you set should be:

"Corporate|Scopes|Internal"

Alternatively, if you know the id of the term, you can set it like this

Set-PnPDefaultColumnValues -List [listname] -Folder -Field [fieldname] -Folder "Test" -Value "6576425f-ecd1-43a3-9be3-564cfefd14aa"

[erwinvanhunen]

We did notice a UI bug though in SPO: when you have special folder names like for instance test, test #1 and you want to set a default column value on the test #1 folder, it's actually setting it on the test folder. E.g. the UI is ignoring the #1 part of the folder name. The Set-PnPDefaultColumnValues cmdlets handles paths with special characters in it, but we're not 100% if SharePoint Online actually does works with those special characters in it when it comes to setting the values on the items. SharePoint uses an event receiver behind the scenes to set the values.

[erwinvanhunen]

A bit additional information on how it works, or rather, where these values are stored: in the root folder of the document library there is a Forms folder. In that folder resides a file called client_LocationBasedDefaults.html. Although the extension is html, the content is actually XML. The cmdlets from PnP modify this file, as the file defines for the event receiver on what value to set. You can retrieve this file yourself by opening https://yourtenant.sharepoint.com/Shared%20Documents/Forms/client_LocationBasedDefaults.html. If you view the source of the file you'll notice that it's XML with a relatively simple structure.

Our cmdlets process this file when handling default column values for a library.

The event receiver associated with the library will also take this file as input for the actions to take. If the event receiver is not aware of the special paths with % or # in it, it will probably not see the value for the special folders and will fall back to the folder name without the characters, e.g. it will use test instead of test #1

[TimTimBS]

@erwinvanhunen Thank you for the input. I'll look into it.
Especially the explanation of how terms are set helped me. Since I copy preset default values, I plan to extract the GUID or the values directly from the string.

Nevertheless I have errors and I think it is actually due to special characters.
When testing with a column without special characters I still got errors.

Maybe it is because the library in the german tenant has a space "Freigegebene Dokumente".

I'll continue testing here and get back to you with a result.

Do you have any further ideas?
Is there a roadmap to fix this bug?

[erwinvanhunen]

No, there is no roadmap for the bug as we from PnP just discovered it. We are not part of the development team of SharePoint, they will have to be notified through one of the many channels and then they will decide if it will be fixed/addressed/looked into. We have no control over that.

[erwinvanhunen]

We will update the cmdlet show a message when a folder is used with a special name, as that unfortunately does not work right now in the current version of SharePoint Online. We noticed that if you create a folder called "test" and a folder called "test #1" and you want to set a value on the "test #1" folder, the value gets set on the test folder when using the UI. However, if you create a folder called "blabla #1234" with no other folders present and you try to set a value on that folder the UI will fail with an error message.

In effect: special folder names do not work. As we unfortunately cannot fix that ourselves I will close this issue.