Upcoming activities: Add MDM commands

[noahtalerman]

Goal

User story
As an endpoint operator on the Host details page,
I want to see a list of the upcoming MDM commands and scripts
so that I know what upcoming commands/scripts will run on a specific host.

Changes

Product

• [ ] UI changes: Figma link
• [ ] REST API changes: Figma link
• [ ] Permissions changes:
  • Admins, maintainers, and observers can see all activity for hosts that they have access to.
  • A user w/ access to specific teams (not global) can only see activity for hosts assigned to this users team(s). If they hit GET /hosts/:id/activities or GET /hosts/:id/activities/upcoming for a host that they don't have access to, they'll get a forbidden response (403) with this error message: Error: You don’t have permission to view activities. The host belongs to a team you don’t have permissions to view.
• [ ] Outdated documentation changes:
  • Add a GET /hosts/:id/activities and GET /hosts/:id/activities/upcoming section in the API for contributors docs. These sections will list all possible activities across all platforms and link to example usage in the REST API docs.
  • In the GET /hosts/:id/activities and GET /hosts/:id/activities/upcoming REST API docs link to the full list of all possible activities in contributor docs.
  • In the release article (or maybe it's own article) describe the first-in-first-out for scripts and MDM commands.
• [ ] Changes to paid features or tiers: Available in Fleet Free and Fleet Premium

Engineering

• [ ] Database schema migrations: TODO
• [ ] Load testing: TODO

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

Context

• Requestor(s): _________________________

QA

Risk assessment

• Requires load testing: TODO
• Risk level: Low / High TODO
• Risk description: TODO

Manual testing steps

1. Step 1
2. Step 2
3. Step 3

Testing notes

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]

@georgekarrv heads up, we moved this story to "Settled." I think we can start the spec'ing process while Rachael takes a look at API design.

@rachaelshaw when you get the chance, can you please take a look at the API design in Figma?

Please let us know if y'all have any feedback or questions.

[marko-lisica]

@roperzh Based on our discussion during design review today. This is behaviour we want:

• For profiles added after this release, we want any new activities to display the latest name of the user (whether the user is deleted or not).
• For profiles added before the release, we’re ok w/ new activities displaying “a user” (because we don’t have a user associated w/ that action)
• Generally, we want activities to reflect the data that is available to Fleet at the time when the activity is generated. We don’t want to update old activities

cc @noahtalerman

[georgekarrv]

@noahtalerman For review

[marko-lisica]

Hey @georgekarrv I assigned myself to the story. I'll double-check if the designs are stale before we proceed.

[noahtalerman]

Hey @georgekarrv, heads up, I pulled the sub-tasks off drafting board (removed :product) to clean up the board. I think we can pull them back on when this story is ready for re-estimation.

cc @marko-lisica

[georgekarrv]

Listing out how this can be split

• MacOS profiles
• Windows profiles
• MDM command macOS
• MDM command Windows
• Disk encryption macOS
• Disk encryption Windows
• Windows Updates
• Locked macOS
• Locked / Unlocked Windows / Linux
• Wiped macOS
• Wiped Windows
• Wiped Linux
• macOS Declarations

team said 3sp for UI for each and 5sp for backend each so napkin math 13*8 -> 104sp but we can slice and dice it to pick and choose which of these to prioritize.

[noahtalerman]

Hey @georgekarrv, @marko-lisica, and @Patagonia121 heads up, I pulled this story and #20301 (and sub-tasks) off the drafting board because it wasn't prioritized in the engineering sprint we just kicked off.

When we revisit this one, let's dig into the building one queue now v. unifying the queue later.