[Fleet] [Managed Policies] Bulk actions changes

[jfsiii]

From #76843

• bulk_reassign
  • [Fleet] Bulk reassign response should include all given ids #95024 Return a 200 response, with an entry for each agent id given
  • [Fleet] Bulk reassign response should include all given ids #95024 Update bulk actions to replace current scaling issues
• bulk_unenroll
  • [Fleet] /bulk_unenroll response matches other bulk action APIs #95571 Return a 200 response, with an entry for each agent id given
  • [Fleet] /bulk_unenroll response matches other bulk action APIs #95571 Update bulk actions to replace current scaling issues
• bulk_upgrade
  • [Fleet] Bulk upgrade api response change #95236 Return a 200 response, with an entry for each agent id given
  • [Fleet] Bulk upgrade api response change #95236 Update bulk actions to replace current scaling issues

Current bulk behavior

If a list of agent ids includes any enrolled in a managed policy

• Bulk reassign filters the managed agents from the list to be reassigned. It reassigns the permitted agents.
• Bulk unenroll filters the managed agents from the list to be unenrolled. It unenrolls the permitted agents.
• Bulk upgrade throws Cannot upgrade agent in managed policy ${policy.id}. It doesn't upgrade any agents.

Proposed bulk behavior

• Bulk reassign, unenroll, and upgrade will all return an array of objects.
• They return a 200 response not 4xx/5xx if any agent ids are enrolled in a managed policy
• There will be one output array entry for each input
  • response shape(s) TBD, perhaps data?: T, error?: Error
  • expand existing pattern used by bulk_reassign

  export type PostBulkAgentReassignResponse = Record<
    Agent['id'],
    {
      success: boolean;
      error?: Error;
    }
  >;
  

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[ph]

Discussion

• Could we include the hostname and the Agent id?
• Some part is inconsistent in the bulk action?
• This is non-blocking because we already implemented the restrictions in 7.12. This issue is about how to improve the UX.

Actions

@mostlyjason @hbharding to lead product discussion for:

• Should we mirror the Elasticsearch behavior for bulk action?
• What is the UI for the bulk action?
• @jfsiii to write down the current behavior. Updated description to include current behavior

[mostlyjason]

@hbharding and I discussed this earlier today. I think we should make the behavior for the bulk actions consistent, both with each other and with Elasticsearch. That means we should switch the upgrade behavior to apply the upgrade to permitted agents. This will allow the user upgrade all the agents they are permitted to. The remaining agents can be upgraded in the external management solution.

To support this workflow in the UI, we discussed updating the existing bulk action confirmation dialog to show a message when the bulk action cannot apply to all the selected agents. It will say something like "2 of the agents you selected cannot be upgraded/reassigned/unenrolled because they are enrolled in an externally managed agent policy". The user can then choose to apply the action or cancel.

I believe @hbharding will add a mockup of the confirmation dialog

[hbharding]

Update 3/29 As we discussed in Slack, we can simplify what I describe below and just disable the checkbox to prevent users from bulk selecting agents that use a hosted agent policy. Please disregard the screenshots below and use the ones provided here https://github.com/elastic/observability-design/issues/32

---

Screenshots for this below. My proposal is that we include a warning callout below the modal's title indicating "X of Y agents you have selected cannot be [action, past tense] because they are enrolled in an externally managed agent policy"

I noticed a small inconsistency with how we implemented bulk actions in the UI. Unenroll and upgrade both open modals, whereas the Assign to new policy action opens a fly out. When I worked on designs for this feature awhile ago, I had intended for these to all use modals and I think it was overlooked. The reason I point this out is that the current "Assign new agent policy" fly out does not give an indication as to how many agents will be affected if it's a bulk action, whereas the other actions do. I'm hoping this will be an easy change to make. If not, we can use the same callout in our existing "assign to new policy" flyout below the flyout header. Ideally we'd also include a count of how many agents will be affected in the flyout title and button in footer.

Assign to new policy as a modal (as intended)

Current bulk reassign flyout

[hbharding]

I provided updated designs for this here elastic/observability-design#32. I wanted to create a separate issue to track work on our obs:design 7.13 board.

[jfsiii]

Closing this ticket. The API work is done and UI issues will be in separate issues/PRs like #96087 based on specs in https://github.com/elastic/observability-design/issues/32