Fleet-maintained apps for macOS

[noahtalerman]

Goal

User story
As an IT admin,
I want to select a Fleet-maintained app
so that I can install the app on my macOS hosts w/o having to upload a package on my own.

Context

• Requestor(s): @mikermcneil
• Product designer: @marko-lisica

This is user story applies to this Fleet Q2 OKR:

• Increase product maturity and fulfill customer promises

Changes

Product

• Add the 20 apps listed in the public Google doc here to Fleet's app library for macOS.
• UI changes: Figma link
  • Research
• Reference documentation changes: WONT(we pushed support for dmg and zip): Check to see if we mention no support of .dmg or .zip in docs. If so, update docs.
• Redirect: Redirect: Fleet-maintained apps for macOS #22580
• CLI usage changes: No CLI changes.
• REST API changes: API design: Fleet-maintained apps for macOS #22552
• Permissions changes: Maintainers and admins (team and global) can view and add Fleet library app. (Team roles can do specified actions to library apps for their team(s) and can add apps to teams they are assigned to.)
• Changes to paid features or tiers: Available in Fleet Premium.
• Other requirements:
  • Bump HTTP request timeout to 15 minutes
  • Support .dmg and .zip for Fleet-maintained apps only in this iteration. Bundle identifier for each app should be hardcoded and used during software title creation

Engineering

• Database schema migrations: Yes

  • Add new table for Fleet app library apps.
  • May also require adding columns to existing software tables.

• Load testing: Yes

  • This feature doesn't itself need load testing, but once it's all done we'll want to do another load test on software installs.

• Documentation changes: Yes

  • We will need a guide written for the Fleet app library (or the existing software library guide is updated to include all options uploads/vpp/library)
  • In the guide, add the definition of "Fleet-maintained": Fleet tests every “Fleet-maintained” app, at the time it's first added to Fleet, to confirm successful install/uninstall using Fleet. Fleet does not actively test each app's new release but will address any bugs when they fail to install/uninstall using Fleet.

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

QA

Risk assessment

• Risk level: Low

Manual testing steps

Test Fleet UI changes -

• Presence of new tab for FMA in the Fleet UI Software page
• Confirm empty state and redirect link works
• Confirm app count and last time updated (tooltip) is accurate
  *Default is 24hrs but you can force by running fleetctl trigger --name maintained_apps
• Test search functionality
• Test that you can edit each app after initial upload and save
• If package already exists on the same team (VPP or custom), ensure that app is not listed as an available FMA

End to End testing -

• Test that all 20 apps install successfully, including via self-service
• Test that all 20 app uninstall successfully (including when open on the host)
• progress was tracked on this spreadsheet

Testing notes

@noahtalerman: We learned that some Microsoft apps (ex. Excel) can point to an XML configuration file at install time to enable/disable certain settings. More info in the "Homebrew format" section in the Google doc here.

We decided to not point to XML in the default install script for these apps because we think the apps can still be installed and used by the end user w/o it. And, we can add Fleet feature for this later.

To be sure, as part of this story, we want to test the following:

• Can the apps that point to an XML config file be installed and used by the end user w/o pointing to the file?
• Can an IT admin update the settings remotely that are normally set in the XML config file after install? Maybe by delivering a profile or running a script?
  • UPDATE: Yes, via profile. More info in the comment section here (@noahtalerman)

As a result

Confirmation

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

[noahtalerman]

User stories are derived from the workflows and problems we want to solve. These are documented here in the public Google doc: https://docs.google.com/document/d/13_xJzKldKiSbRknsDFADIf3sESNHapj-7D24Hyu4qro/edit

[noahtalerman]

This story is related to the "Automate Zoom updates" story (#18961).

The user story "Automate Zoom updates" story will be addressed by this story.

[marko-lisica]

Hey @dherder, we're missing customer/prospect labels for this one. Could you please add labels when you get a chance?

[dherder]

@marko-lisica this looks to be a duplicate of #17129

[marko-lisica]

Thanks @dherder! I think we should keep both, since this one will be focused on software install in case of policy failure. @noahtalerman What's your take on this?

[noahtalerman]

I think we should keep both

Agreed.

@dherder this story enables this workflow: policy failure => trigger software install (software you've previously uploaded to Fleet). No Tines needed.

I think #17129 is similar but for script: policy failure => trigger script. No Tines needed.

What do you think? Any feedback?

[dherder]

sounds good to me, @noahtalerman.