[Ingest Manager] Bulk unenroll and force unenroll

[mostlyjason]

User stories
For example: as an admin, I can create teams and invite new members

• As a fleet admin, I need a way to gracefully unenroll many agents at the same time (in bulk).
• As a fleet admin, I need a way to force unenroll many agents at the same time (in bulk).
• As a fleet admin, I need text explaining the difference between unenroll and force unenroll.

List known (technical) restrictions and requirements
None

Other
Related issues:
#67704
#72386

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[mostlyjason]

@hbharding here is another idea: there is only one action to unenroll agents, and in the confirmation modal there is an option to force the unenrollment and delete queued data? This explains the difference and simplifies the choices in the bulk actions menu.

[mostlyjason]

One more idea: the default action is regular unenroll. If any agents are not responsive, we can ask if the user would like to force unenroll them. This is similar to the copy action on windows, which confirms how you want to deal with conflicting files.

[hbharding]

Update:

While working on bulk actions, I realized that our current behavior for when to show a "force unenroll" option is complicated when it comes to bulk actions. The current behavior is to only show "Force unenroll" as an option if the agent is in a "unenrolling" state. But what happens if a user bulk selects 1,000 agents, and several of those agents are already in an unenrolling state? Do we show "force unenroll" as an available option, or should it be disabled because not all agents are unenrolling? Will the user understand the difference between "Unenroll" and "Force unenroll" when shown side-by-side in a context menu? And should the user be able to unenroll an agent that is already in an unenrolling state? I think by our current logic, in this situation both options would be disabled, and I think this could be confusing for the user. The user could get around this by first filtering the agents to only show ones that are "unenrolling", and then select all and do "Force unenroll"... but that seems like a lot of steps and relies on user intuition. I think we can simplify.

@mostlyjason shared an interesting idea during a recent design review. Perhaps "force unenroll" could be an option that is part of the "unenroll agent" modal. The input would be turned off by default.

Pros:

• I think it simplifies and solves a lot of the questions mentioned above. "Unenroll" would always be available for bulk actions, regardless of an agent's current state.
• It merges two related ideas into a single interface and allows space to explain what "force unenroll" means.
• It would allow users to "force unenroll" agents if they want. I think there could be uses cases to support this. For example, "my agent's host is compromised and I need to stop the agent immediately. I don't care about losing any data or receiving a last message"

Cons:

• It's an extra option / more cognitive load. However, the current alternative also feels complicated.
• By exposing it here, we may be promoting behaviors that we don't want to encourage. Could this lead to weird scenarios which I haven't considered?

[mostlyjason]

Looks good I like it! For force unenroll I think the difference is that we don't wait for the agent. Could we update the text to say something like "Don't wait for the agent to send its last events"?

[hbharding]

updated screenshots