Monthly Archives: September 2018

SharePoint Online: displayname bug in sitecolumn provisioning (?)

On my current project, I’m provisioning a set of sitecolumns with powershell.
I have a JSON file with a collection of sitecolumn definitions that looks like this:

"name": "fg_contact",
"xml": ""

And I use this powershell code:

$fieldAsXML = $JSON.xml
$fieldOption = [Microsoft.SharePoint.Client.AddFieldOptions]::AddFieldInternalNameHint
$field = $fields.AddFieldAsXML($fieldAsXML, $true, $fieldOption)

First time I provisioned the sitecolumns like this, my profile had English as default language. It the result was as expected; my ‘fg_contact’ field was displayed as ‘Contact’
Second time I provisioned with this solution, I used another tenant, one where my profile was set to Dutch.
I was quite surprised to see most of my sitecolumns displayed with the internal name.

Funny thing: see how the managed metadata fields did get the correct displayname…? (the provisioning xml for these columns is exactly the same!)

So I started testing a couple of scenarios to see what was happening.
Starting of with an English profile, provisioning the sitecolumns, gave me the correct result. After switching to a Dutch profile, I still got the correct displaynames.

Provisioning with an Dutch profile gave me the wrong result (see previous image). After switching to a English profile, I still got the wrong displaynames.

And yes, even after adding LCID=’1043′ to the XML didn’t make any difference.

So, any thoughts, any one?

BTW: as far as I can tell, this also goes for provisioning from within an SharePoint Framework webpart