Uncomments this attribute; adds validation function.
I believe General.RedeployOnUpdate is in the GUI - just in an unexpected way.
When a profile is updated (content or scope or any other attr) in the GUI, the operator is prompted with a "Redistribution Options" modal:
The second option, "Distribute to Newly Assigned Devices Only", seems to match what appears to be the only value every returned (in my environments) for redeploy_on_update: the string "Newly Assigned". (Retrieved from raw API responses.)
I've tested with my dev env. Behavior seen:
TF apply updates a profile + the profile resource & api request set redeploy_on_update: "Newly Assigned" -> Jamf sends new MDM InstallProfile commands to any new computers in scope.
TF apply updates a profile + the profile resource & api request set redeploy_on_update: "All" -> Jamf sends new MDM InstallProfile commands to all computers in scope.
However, after sending a successful CRUD API request with redeploy_on_update: "All", subsequent API get requests will continue to show "redeploy_on_update: Newly Assigned". That is, redeploy_on_update behaves as a parameter governing the current CRUD operation, not as an attribute on the profile object.
So: this delta proposes we never read General.RedeployOnUpdate from the API, but allow it to be set in the TF state solely by the TF config. This value is then set on all future CRUD API requests, governing Jamf's behaviour in a consistent, TF config'd manner.
Should there be a doc update too? (Or tests?) Happy to w/ either!
Read payload content
Adds plist.Unmarshal deserialization of General.Payloads into TF state's payload.
Added to enable future import support - but more to understand what drift Jamf introduces into unsigned profile payloads created by this provider.
My testing has lead me to suspect new keys are injected on some payload types. (Jamf certainly signs the payload for deploy.) It does seem to rewrite profile display names at will for many payload types, causing perpetual drift.
Unrelated bug fix
err := d.Set("scope" -> err = d.Set("scope"
The compiler yelled at me.
Enable
redeploy_on_updateUncomments this attribute; adds validation function.
I believe
General.RedeployOnUpdateis in the GUI - just in an unexpected way.When a profile is updated (content or scope or any other attr) in the GUI, the operator is prompted with a "Redistribution Options" modal:
The second option, "Distribute to Newly Assigned Devices Only", seems to match what appears to be the only value every returned (in my environments) for
redeploy_on_update: the string "Newly Assigned". (Retrieved from raw API responses.)I've tested with my dev env. Behavior seen:
redeploy_on_update: "Newly Assigned"-> Jamf sends new MDM InstallProfile commands to any new computers in scope.redeploy_on_update: "All"-> Jamf sends new MDM InstallProfile commands to all computers in scope.However, after sending a successful CRUD API request with
redeploy_on_update: "All", subsequent API get requests will continue to show"redeploy_on_update: Newly Assigned". That is,redeploy_on_updatebehaves as a parameter governing the current CRUD operation, not as an attribute on the profile object.So: this delta proposes we never read
General.RedeployOnUpdatefrom the API, but allow it to be set in the TF state solely by the TF config. This value is then set on all future CRUD API requests, governing Jamf's behaviour in a consistent, TF config'd manner.Should there be a doc update too? (Or tests?) Happy to w/ either!
Read payload content
Adds
plist.Unmarshaldeserialization ofGeneral.Payloadsinto TF state'spayload.Added to enable future import support - but more to understand what drift Jamf introduces into unsigned profile payloads created by this provider.
My testing has lead me to suspect new keys are injected on some payload types. (Jamf certainly signs the payload for deploy.) It does seem to rewrite profile display names at will for many payload types, causing perpetual drift.
Unrelated bug fix
err := d.Set("scope"->err = d.Set("scope"The compiler yelled at me.