Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plist Normalization Errors on mobiledeviceconfigurationprofilesplist Resource #601

Open
leggatron opened this issue Feb 26, 2025 · 0 comments

Comments

@leggatron
Copy link
Contributor

leggatron commented Feb 26, 2025

Issue:

We have been writing some modules against this to automatically create a .mobileconfig plist in Jamf Security Cloud, collect the plist output, and upload it to Jamf Pro as a Configuration Profile. This works fine with macOS but not with iOS/iPadOS.

The error we're getting back looks like this when trying to apply that plist in line within the same module:

When expanding the plan for module.jsc_all_services[0].jamfpro_mobile_device_configuration_profile_plist.all_services_mobile to include new values learned so
│ far during apply, provider "registry.terraform.io/deploymenttheory/jamfpro" produced an invalid new value for .payloads: was cty.StringVal(""), but now
│ cty.StringVal("<?xml version=\"1.0\"

This continues but I cut it off at the top of the plist file xml heading

What we think is happening:

We noticed that this function seems to be placing the double quotes in the city.StringVal since it doesn't immediately see the plist coming over and that cause the whole module to error out. However, when we do the same with macOS, that issue does not happen which we believe is due to this plist.NormalizePayloadState function not being included for the macOS version of this resource.

The plist passes fine on a second terraform apply so we know that it works but we think this normalization check is blocking the initial module from applying.

Request:

We were wondering if this function could be removed without a major effect on other use cases -or- if we could have a method of bypassing it like we have with the payload_validate function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant