Feature request : proper handling of content types published from the new CTHUB (or maybe a bug report?)

Category

• Feature request

Describe the feature

The new content type hub behaves a bit differently from the legacy one. Specifically regarding the inheritance.

For example, let's say I have in my CTHUB this inheritance hierarchy:

Document (OOB) ==> Corporate document ==> HR document

Corporate document isn't meant to be used directly, but is used to hold generic fields, used across the organization. HR Document is a more specific type of document shared by a few site collections.

That's why we publish only HR document from the CTHUB.

If I add the HR document CT to a list, only the "leaf" CT will be provisioned in the site. In the "classic" content type experience, we can see Document is the parent of HR document, even though the IDs suggests there's something else between.

This is working fine when using the GUI only.

However, the PnP Provisioning engine does not take this specific case into account. using Get-PnPSiteTemplate outputs an XML file that reflects the final content types, without the "missing" intermediate content type. And without any clue that's the CT is issued from the CTHUB (actually the SourceID reflects the cthub web's ID, but that's not portable across tenant).

The export itself doesn't fail, but the import will. Calling Invoke-PnPSiteTemplate fails with something like Parent content type with ID abc1234 doesn't exixts. Which is true, because it missed the intermediate content type.

Describe the solution you'd like

I'd like the provisioning engine to be extended to support content type subscription. There's a cmdlet to subscribe to a content type (Add-PnPContentTypeFromContentTypeHub). So I guess the solution will consists in :

• extending the schema to add a <pnp:ContentTypeRef Id="0x01...."/> or similar
• add a new handler that will works before the existing fields and contenttype handlers

Additional context

My environment have this content types (100% build using the GUI) :

• Content type hub (each variation adds a 01 at the end in the ID):
  • Document : 0x0101
  • Corporate document : 0x0101006C86C9CE18284A40923FBED974C8F011
  • HR Document : 0x0101006C86C9CE18284A40923FBED974C8F01101
  • HR Document type 1 : 0x0101006C86C9CE18284A40923FBED974C8F0110101
• A site collection where I added the HR document type 1 in the "Documents" library (IDs are collected from the classic content type administration page. If not, the IDs are the one from the content type hub)
  • Document : 0x0101
  • HR Document type 1 : 0x0101006C86C9CE18284A40923FBED974C8F0110101

The exact error message when using the template is : Invoke-PnPSiteTemplate: Le type de contenu parent spécifié par l’identificateur de type de contenu 0x0101006C86C9CE18284A40923FBED974C8F01101 n’existe pas.

No source files or tests are named. Start by locating the provisioning schema and the existing fields and content type handlers referenced in the issue, then trace how Get-PnPSiteTemplate exports inherited content types and how Invoke-PnPSiteTemplate imports them. Done means a template preserves the content type subscription and imports successfully without the missing-parent error.