Follow-up to #436 / #437, which fixed this for blueprint legacy_payloads only.
What happens
A com.apple.ManagedClient.preferences payload carrying several preference domains under one PayloadContent dictionary is applied one domain at a time by a Mac, which drops the rest and reports nothing. Wire evidence and the unpredictability of which domain survives are in #436.
#437 refuses that shape at plan for component_blocks[].legacy_payloads and the deprecated top-level legacy_payloads. Three other surfaces can still emit it, with no plan-time refusal and no documentation:
jamfplatform::mobileconfig — the profile argument carries author-written payloads verbatim, and examples/functions/mobileconfig/function.tf builds an MCX envelope by handjamfplatform_pro_macos_configuration_profile — a .mobileconfig payload passes throughjamfplatform_pro_mobile_device_configuration_profile — same, though managed preferences are not delivered this way on iOS, so probe before assuming the rule applies
jamfplatform::mcx_forced_payload takes a single domain per call and cannot express the shape, so that path is already safe.
Why it is filed separately rather than fixed in #437
The blueprint fix lives in internal/resources/blueprints/blueprint/validators.go and keys on a payload-type constant local to that package. The profile resources compare and mask payloads through internal/common/payloadhelpers, which already holds its own copy of the payload type (mcxLikePayloadTypes, importgate.go). A shared check belongs in payloadhelpers or appleprofiles, and deciding which is a design question rather than a port.
Open questions
- Which package owns the rule, given
appleprofiles.Validate deliberately stops descending at the free-form dictionary the domains sit under
- Whether a provider-defined function can carry a plan-time refusal usefully, since a function has no attribute path to report against
- Whether the rule applies to iOS at all. Every device observation behind it is macOS 26.6
Not in scope
Nothing here changes what the provider sends today on those three surfaces. They are unchanged by #437 and behave as they always have.
Follow-up to #436 / #437, which fixed this for blueprint
legacy_payloadsonly.What happens
A
com.apple.ManagedClient.preferencespayload carrying several preference domains under onePayloadContentdictionary is applied one domain at a time by a Mac, which drops the rest and reports nothing. Wire evidence and the unpredictability of which domain survives are in #436.#437 refuses that shape at
planforcomponent_blocks[].legacy_payloadsand the deprecated top-levellegacy_payloads. Three other surfaces can still emit it, with no plan-time refusal and no documentation:jamfplatform::mobileconfig— the profile argument carries author-written payloads verbatim, andexamples/functions/mobileconfig/function.tfbuilds an MCX envelope by handjamfplatform_pro_macos_configuration_profile— a.mobileconfigpayload passes throughjamfplatform_pro_mobile_device_configuration_profile— same, though managed preferences are not delivered this way on iOS, so probe before assuming the rule appliesjamfplatform::mcx_forced_payloadtakes a single domain per call and cannot express the shape, so that path is already safe.Why it is filed separately rather than fixed in #437
The blueprint fix lives in
internal/resources/blueprints/blueprint/validators.goand keys on a payload-type constant local to that package. The profile resources compare and mask payloads throughinternal/common/payloadhelpers, which already holds its own copy of the payload type (mcxLikePayloadTypes,importgate.go). A shared check belongs inpayloadhelpersorappleprofiles, and deciding which is a design question rather than a port.Open questions
appleprofiles.Validatedeliberately stops descending at the free-form dictionary the domains sit underNot in scope
Nothing here changes what the provider sends today on those three surfaces. They are unchanged by #437 and behave as they always have.