Policy automation: re-send configuration profile

[noahtalerman]

• @noahtalerman: After we build this, we want to switch to using this policy automation logic for certificate renewal.

Goal

User story
As an IT admin,
I want policy automations that re-send configuration profiles
so that I can renew certificates, fix Santa, fix Wi-Fi, automated CIS Benchmark enforcement, and more...

Changes

Product

• UI changes: Figma
• CLI (fleetctl) usage changes: No changes
• YAML changes: [YAML] Update YAML documentation for policy automations #51049
• REST API changes: [API] Update parameters and examples in REST API documentation #51051
• Fleet's agent (fleetd) changes: No changes
• Fleet server configuration changes: No changes
• Exposed, public API endpoint changes: No changes
• fleetdm.com changes: No changes
• GitOps mode UI changes: The new automation row appears as read-only (disabled) in GitOps mode, same as install_software and run_script.
• GitOps generation changes: fleetctl generate-gitops outputs resend_configuration_profile in the policy YAML, mirroring how install_software and run_script are serialized.
• Activity changes:
  • Include optional fields for policy_id and policy_name in existing resent_configuration_profile activity
  • [Activity] Update audit log fields for policy information #51082
• Permissions changes: No changes
• Changes to paid features or tiers: Fleet Premium
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes:
  • [Docs] Enhance automations documentation with configuration profiles #51141
  • [Route] Add route for policy automation resend configuration #51142
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed

Engineering

• Test plan is finalized
• Contributor API changes: No changes
• Feature guide changes: Covered via [Docs] Enhance automations documentation with configuration profiles #51141
• Database schema migrations: See subtasks

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

• Risk level: Low

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

• Create a team policy with resend_configuration_profile automation pointing at a profile assigned to a host
• Host passes the policy initially → no resend triggered
• Host fails the policy (pass→fail) → profile status set to NULL, profile is re-delivered
  • Verify with Windows and Apple profiles
• Profile not assigned to the host(e.g. different label scoping on the profile) → no-op, no error
• Profile status is pending or verifying → no-op (don't interrupt in-flight delivery)
• Verify that if "Continuous software & script automations" enabled, it doesn't affect resend profiles
• Change the selected profile on the policy → host memberships/stats reset, resend triggers on next failure
• Remove the automation (set to null in API / remove from YAML) → no resend on failure
• Global policy → cannot add resend_configuration_profile (rejected at save time)
• Profile from a different team(e.g. set via API) → rejected at save time (team scoping)
• Test two policies targeting same profile -> Allowed
• Verify that UI and API do not allow setting Apple declarations or Android profiles for resend
• Delete a config profile referenced by an automation -> Verify it is blocked with a reasonable error
  • Remove the automation reference, then try deleting it again. Verify it succeeds
  • Test with Windows and Apple profiles
• Verify profile reference can not be set when platforms does not contain apple or windows
• Verify profile reference can not be a Fleet managed profile (such as FileVault or Windows OS updates)

Edge cases

• TODO

Supplemental testing

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
2. QA: Added comment to user story confirming successful completion of test plan.
3. QA: Determined whether this story needs Playwright automation.
   • Needs automation: Yes / No
   • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation":