There is a bug/limitation in SharePoint that we need to be aware of whenever we create a new Managed Metadata field in our provisioning templates.
Background
A Managed metadata field always consists of two fields, A TaxonomyField and a hidden TextField. The TaxonomyField is connected to TextField by specifying the ID of the field in the TextField property for the TaxmonyField Schema XML. Vice versa, the text field is connected to the TaxonomyField by specifying the ID of the TaxonomyFied (without hyphens) in the Name and StaticName properties for the TextField Schema xml.
Example
TextField Schema XML:
<Field ID="{09718d7c-056d-4473-9eca-cf7ad02eb1d7}" Name="ada574e21bd64ab4ae0d55c9caaa200b" StaticName="ada574e21bd64ab4ae0d55c9caaa200b" DisplayName="{res:Field_Template_sets_0_DisplayName}" Type="Note" ShowInViewForms="FALSE" Required="FALSE" Hidden="TRUE" CanToggleHidden="TRUE" AllowDeletion="FALSE" />
TaxomoyField Schema XML:
<Field ID="{ada574e2-1bd6-4ab4-ae0d-55c9caaa200b}" Name="wpTemplateSets" StaticName="wpTemplateSets" DisplayName="{res:Field_Template_sets_DisplayName}" Description="{res:Field_Template_sets_Description}" Group="WorkPoint Site Columns" Type="TaxonomyFieldTypeMulti" List="{{listid:TaxonomyHiddenList}}" ShowField="Term1033" Required="FALSE" EnforceUniqueValues="FALSE" Mult="TRUE" Sortable="FALSE" AllowDeletion="FALSE">
<Customization>
<ArrayOfProperty>
...
<Property>
<Name>TextField</Name>
<Value xmlns:q6="http://www.w3.org/2001/XMLSchema" p4:type="q6:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">
{09718d7c-056d-4473-9eca-cf7ad02eb1d7}</Value>
</Property>
...
</ArrayOfProperty>
</Customization>
</Field>The issue
There seems be a bug in SharePoint which is triggered when a content type is added to a list and the content type has a Managed Metadatafield where the GUID ID of a TaxonomyField starts with number instead of a letter.
We have recently seens this bug with our field wpEntityEvent:
<Field Type="Note" DisplayName="wpEventType_0" StaticName="45cfac463d014f47b67598b12d2d5cdd" Name="45cfac463d014f47b67598b12d2d5cdd" ID="{7e16d63b-ba18-45c2-b6c3-5258a9c470f6}" ShowInViewForms="FALSE" Required="FALSE" Hidden="TRUE" CanToggleHidden="TRUE" />
<Field ID="{45cfac46-3d01-4f47-b675-98b12d2d5cdd}" StaticName="wpEventType" Name="wpEventType" DisplayName="{res:Field_EventType_DisplayName}" Description="{res:Field_Event_Type_Description}" Type="TaxonomyFieldType" List="{{listid:TaxonomyHiddenList}}" WebId="{siteid}" ShowField="Term1033" Required="TRUE" EnforceUniqueValues="FALSE" Group="WorkPoint Site Columns" SourceID="{{siteid}}">
...
</Field>When the content type is added to a list, SharePoint will thrown an error saying a duplicate field was found.
The can be recreated by following these simple steps:
- Create a Custom list
- Enable content types on list
- Add content type to list (e.g. Entity Event) which has a MetadataField where the ID of the field starts with a number
SharePoint will then throw this error:
But the field is actually added to the list
By inspecting the field on the list we can see that the StaticName and Name for the TextField is not what we expect:
However on the Site Column the values are what we expect
Conclusion
We have seen that when a TaxonomyField is created with an ID that starts with a number, SharePoint doesn't follow the typical pattern for setting the StaticName and Name on the hidden TextField. Instead it replaces the first character in StaticName with an unicode character. This causes an issue when a content type with the field is added to a list.
To avoid this issue we must ensure that whenever we add a new Managed Metadata field to any of our templates, the TaxonomyField must have an ID which starts with a letter.
Comments
0 comments
Please sign in to leave a comment.