Not possible to config patch the fieldFilter exclude list

[jammykam]

Do you want to request a feature or report a bug?
Report a bug

What is the current behavior?
It is not possible to patch:delete any of the exclude fieldFilter entries from the Unicorn.config file because this these elements currently do not use a significant attribute .

If the current behavior is a bug, please provide the steps to reproduce.

Create a patch config file which attempts to delete the __Revision field, then check /sitecore/admin/showconfig.aspx. You will note the revision field is still present, and instead the first entry from the list (Last Run) has been deleted instead.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore role:require="Standalone or ContentManagement">
    <unicorn>
      <defaults>
        <fieldFilter>
          <exclude note="'__Revision' field on Standard Template">
            <patch:delete />
          </exclude>
        </fieldFilter>
      </defaults>
    </unicorn>
  </sitecore>
</configuration>

What is the expected behavior?
The expected behaviour is that the specified element would be deleted, or patched. This will only be possible if the attributes are changed to one which is a significant attribute. I suggest changing the note attribute in this section to instead use desc.

This issue is specifically an issue when using Sitecore Publishing Service, and genarating IAR files from Unicorn. SPS requires the Revision field to be present.

Please mention your Sitecore version and Unicorn version.
Sitecore 10.2, Unicorn 4.1.6

[cassidydotdk]

Perhaps asking the obvious, but why not patch it using

<exclude fieldID="{B1E16562-F3F9-4DDD-84CA-6E099950ECC0}"> ?

While I agree, your approach should actually work and I'm not entirely sure what trips up Sitecore Configuration Factory here... but my suggestion is just as valid. It's not like this field ID is ever going to change :)

[cassidydotdk]

That said; hint is probably the more appropriate attribute to use. But your point is taken.

Would still love to know if using fieldID will allow a workaround.

[jammykam]

No, fieldID did not work either, it behaved in the same way as note since it is not on the significant attributes list either.

[cassidydotdk]

Yea I noticed. fieldId is, fieldID is not. I'll get something in that will allow this to be patched.