Grouped policy failure display

[iansltx]

• @noahtalerman: User requested this because they anticipate that users with hundreds of hosts will get a flood of activities when they add a policy automation. This will bump down other important activities.

---

[noahtalerman]

Goal

User story
As an administrator,
I want to see actions taken for the same policy grouped rather than one per host
so that I can easily scan the activity feed for distinct types of events.

Objective

TODO /cc @spokanemac

Context

• Product designer: _____

What else should contributors keep in mind when working on this change?

This could be handled to some extent front-end-only with no API changes, but activity grouping may be a powerful primitive for customers with larger host counts, particularly for patching flows that will consistently fail existing hosts as new versions of a software package are rolled out. So an initial revision of this might be FE-only, with a new grouped activities endpoint (or query parameter) as a follow-on.

Changes

Product

• [ ] UI changes: TODO
• [ ] CLI (fleetctl) usage changes: No changes
• [ ] YAML changes: No changes
• [ ] REST API changes: Potential changes to global activities endpoint, depending on FE-only vs. combined implementation
• [ ] Fleet's agent (fleetd) changes: No changes
• [ ] Activity changes: TODO
• [ ] Permissions changes: No changes
• [ ] Changes to paid features or tiers: No changes
• [ ] Other reference documentation changes: No changes
• [ ] Once shipped, requester has been notified

Engineering

• [ ] Feature guide changes: May need to update https://fleetdm.com/guides/automations#activity-automations
• [ ] Load testing: Will need to confirm performance due to higher row counts scanned when the activity feed is shown for a large number of events/hosts

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

QA

Risk assessment

• Requires load testing: Yes
• Risk level: Medium
• Risk description: For large customers (wo this behavior would benefit if they use policy automations for installs or scripts) we may have decreased performance of the activities endpoint, though that endpoint would return more data in exchange.

Manual testing steps

1. Create a policy automation for an install or script run
2. Fail that policy across a bunch of hosts, causing the automation to run
3. Look at the global activity feed and confirm that activities are grouped, with hosts visible if you drill down.

Confirmation

1. [ ] Engineer (@____): Added comment to user story confirming successful completion of QA.
2. [ ] QA (@____): Added comment to user story confirming successful completion of QA.

[noahtalerman]

Hey @iansltx thanks for tracking this one. We're setting it to the side b/c it doesn't meet the criteria for prioritizing a feature: https://github.com/fleetdm/fleet/pull/23184/files#diff-c99d12c3af50c0c2aca2b9ef7597c02ccfe87678291956ff0b2e83d63978ea38R370

I'm guessing this one is a little bit too large to call a small UX improvement.

[noahtalerman]

@iansltx: My bet is that this will come up as a customer pain point as soon as we have larger fleets of machines using policies to keep software patched, so this is really a question of whether we build before the pain we know customers will see, or after.

Noah: Make sense! I think let’s dogfood it first. Feel the pain ourselves. That way, we can come up w/ the best solution.

@lukeheath heads up that it looks like this request got the ~dogfood label but I don't think we're dogfooding the feature: automatically install software (via policy automation) yet.

It would be great to dogfood that feature! Removing the ~dogfood label for now.