mirror of
https://github.com/fleetdm/fleet
synced 2026-05-24 09:28:54 +00:00
c2eb45f9a7
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #43738 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [ ] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [ ] Timeouts are implemented and retries are limited to avoid infinite loops - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [ ] Where appropriate, [automated tests simulate multiple hosts and test for host isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing) (updates to one hosts's records do not affect another) - [x] QA'd all new/changed functionality manually - Before the fix, switching from custom package to FMA via GitOps created two software installer rows and duplicate setup experience installers (the setup experience page said "2 software items will be installed during setup" even though only one was selected. - After the fix, switching from custom package to FMA via GitOps deleted the old installer and left only one row with the correct FMA. In setup experience, only one instance of the software was installed. - Added a custom package (obsidian) and a policy with a software install automation for it, then applied gitops and replaced obsidian with the FMA version and the policy with the FMA slug, and it redirected the policy to the new installer. - Adding setup experience software will only set `install_during_setup=1` on the active FMA, and not on installer rows with `is_active=0` <img width="1222" height="558" alt="image" src="https://github.com/user-attachments/assets/ace5922a-63ec-4591-b615-1a8534a70805" /> <img width="1173" height="483" alt="image" src="https://github.com/user-attachments/assets/05c7c718-4f4a-4549-bbf1-1e1d6dae75d0" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Prevent duplicate installs by ensuring only active installers are considered during setup; remove or replace custom installers when a managed (fleet‑maintained) installer is added, repointing policies to the active installer and canceling now-obsolete pending setup actions. * **Tests** * Added tests covering active-installer selection, custom→managed installer replacement, policy repointing, display-name preservation, and cancellation of pending setup activities. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
1 line
174 B
Text
1 line
174 B
Text
- Fixed a bug where custom package installers were not removed when adding an FMA for the same title via GitOps, which caused setup experience to install duplicate software.
|