Ability to release a device from AB from Fleet UI and/or API

[melpike]

Goal

User story
As an IT admin,
I want to be able to release a host from AB via Fleet UI/API
so that I don't have to sign into AB to do it (in case I don't have access to AB).

Changes

Product

• UI changes: Figma
• CLI (fleetctl) usage changes: No changes
• YAML changes: No changes
• REST API changes:
  • [API] Add 'Release host from AB' section to API docs #48972
  • For batch requests, if a failure returns for host show error message (what we get back from Apple).
• 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: No changes
• GitOps generation changes: No changes
• Activity changes:
  • New type: "Released host from Apple Business"
  • [Activity] Enhance audit logs documentation with examples #48976
• Permissions changes: Admin-only (team admin for team hosts, global admin for all)
• Changes to paid features or tiers: Fleet Premium only
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes: [Docs] Document host release process from Apple Business #49148
• 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: None
• Feature guide changes: See above, [Docs] Document host release process from Apple Business #49148
• This is a premium only feature: Yes (ABM is premium)

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

Risk assessment

• Risk level: Low
• Risk description: The biggest risk here is that an admin unintentionally releases the wrong device which is not an easy situation to resolve, particularly for those who do not

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.

Be sure to test with device that you're ok with not having in AB for a while. The release action itself is instantaneous and irreversible.

Core flow

• Test all cases below with a single AB token configured and multiple AB tokens and test with macOS, iPadOS and iOS devices
• Navigate to Host details for an Apple host enrolled via AB.
• Verify "Release from AB" action is visible for an eligible host (AB enrolled and MDM on).
• Click "Release from AB" and confirm tahe confirmation modal appears.
• Confirm the action. Verify the API call succeeds and a success banner is shown.
• Verify the host's MDM status details modal shows new updated error messaging.
• Verify a new activity "released_host_from_ab" appears in the global activity feed with the correct actor, host display name, host serial, and timestamp.
• Test with batch request via API with hosts that will succeed and fail. Ensure error message shows for hosts that failed.
• Test that a releasing a device configured against token without the setting in AB that allows the MDM server to release devices fails with a reasonable error message
• Verify that non-AB devices do not show the release option
• Assign a device to another server in AB then try to release it. Verify that a reasonable error is returned
• Verify in the UI and API that only admins can release hosts, singly or multiple. Observer, maintainer, technician cannot.
• Verify via the API that a team-scoped admin cannot release hosts from another team

Feature in isolation/Fleet Free

• Verify that with Apple MDM disabled and on Fleet Free the Host page still loads and is functional for Apple hosts
• Verify that with Apple MDM disabled proper errors are returned when attempting to hit the release endpoint on Fleet Premium
• Verify that on Fleet Free the usual Premium-only error is returned when attempting to hit the release endpoint

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":