Skip to content

Add apps installed through Windows app store to software inventory #14717

Description

@zayhanlon

Goal

User story
As an endpoint engineer on the Software page,
I want to see Windows apps installed via the Windows app store
so that I know which Windows app store apps are installed on my hosts.

Changes

Product

  • UI changes: Figma
  • CLI (fleetctl) usage changes: No changes
  • YAML changes: No changes
  • REST API changes: No changes
  • Fleet's agent (fleetd) changes: No changes
  • Fleet server configuration changes: No changes
  • Exposed, public API endpoint changes: No changes
  • fleetdm.com changes: No changes
  • GitOps mode UI changes: No changes
  • GitOps generation changes: No changes
  • Activity changes: No changes
  • Permissions changes: No changes
  • Changes to paid features or tiers: Fleet Free
  • My device and fleetdm.com/better changes: No changes
  • Usage statistics: No changes
  • Other reference documentation changes: No changes
  • First draft of test plan added
  • Once shipped, requester has been notified
  • Once shipped, dogfooding issue has been filed

Engineering

Sub-tasks:

Windows app store apps (packaged MSIX/AppX apps such as Microsoft Copilot) already reach software inventory as source='programs' via osquery 5.23.1 and already render on the Software page — they just carry the same "Program (Windows)" type label as classic Win32 installers. The only change this story needs is to rename that type label to "Application (Windows)" so the category reflects that Windows app store apps are included (per the Figma dev note). This is a blanket rename: all Windows programs software adopts the new label; store apps are not broken out separately.

No backend, migration, API, or documentation changes are required. The earlier backend (#49051), documentation (#49053), and engineering-QA/NVD-assessment (#49054) sub-tasks were closed as not needed — the data is already ingested and already vulnerability-scanned via NVD; only the frontend label changes.

  • Test plan is finalized
  • Contributor API changes: No changes.
  • Feature guide changes: No changes.
  • Database schema migrations: No changes.
  • Load testing: Not required. Frontend-only label rename; no new query, cron, table, or column.
  • Pre-QA load test: Not required. The change does not modify Fleet's load profile.
  • Load testing/osquery-perf improvements: None.

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

Risk assessment

  • Requires testing in a hosted environment: No. A local Windows host with a store app installed is sufficient.
  • Requires load testing: No.
  • Risk level: Low
  • Risk description: Frontend-only label rename in SOURCE_TYPE_CONVERSION. No data, schema, or API changes. Only regression to watch is stale unit-test/snapshot expectations of "Program (Windows)".

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

  • On an enrolled Windows host, install a Windows app store app (for example Microsoft Copilot or Windows Terminal) and refetch host vitals. Confirm it appears in the host's software list with type "Application (Windows)".
  • Confirm a classic Windows program (for example 7-Zip installed via .exe) also shows "Application (Windows)" — this is a blanket rename; no source='programs' software shows "Program (Windows)" anymore.
  • Confirm the new label appears everywhere the Windows programs type is shown: the Software page (title list), Host details > Software, and the software title details page.

Edge cases

  • Non-Windows hosts and non-programs software sources are unaffected (labels unchanged).
  • Server upgraded from a prior version: the label change is frontend-only and applies immediately; no data migration involved.

Supplemental testing

Testing notes

Confirmation

  1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
  2. QA: Added comment to user story confirming successful completion of test plan.
  3. QA: Determined whether this story needs Playwright automation.
    • Needs automation: Yes / No
    • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation":

Metadata

Metadata

Assignees

Type

No type

Projects

Status
No status
Status
🎗️ Feature request
Status
✔️Awaiting QA

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions