For #23531.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] Added/updated automated tests
- [x] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
Related to: #25170
Changes:
- Updated the `view-profiles`, `get-profiles`, `edit-profile`, and
`upload-profile` actions to send requests to the connected Fleet
instances and process results simultaneously.
I tested these changes while connected to a Fleet instance running on
the same network as my device, here is what I saw:
- Loading the profiles page with four profiles assigned to 22 teams:
- Current version: 3232ms
- This PR: 699ms
- Uploading a configuration profile with custom label targets to 22
teams:
- Current version: 5660ms
- This PR: 865ms
- Editing a configuration profile that is assigned to 22 teams labels:
- Current version: 6622ms
- This PR: 1300ms
- Replacing an existing configuration profile assigned to 22 teams:
- Current version: 6483ms
- This PR: 1773ms
- Fetching up-to-date configuration profile information from the Fleet
instance after a change is made:
- Current version: 2857ms
- This PR: 736ms
_Merge only _after_ https://github.com/fleetdm/fleet/pull/25322_
## For #25319
- Team admin can access SSO and 2FA options in user form when they are
enabled (see api response to right):
<img width="1799" alt="Screenshot 2025-01-10 at 1 36 10 PM"
src="https://github.com/user-attachments/assets/66bd5eea-dc1d-4e5b-85fc-b377520f337a"
/>
- [x] Changes file added for user-visible changes in `changes/`,
- [ ] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
> For #25194
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [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/Committing-Changes.md#changes-files)
for more information.
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] Added/updated automated tests
- [x] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
For batch upload of Apple DDM profiles with `fleetctl gitops`, fixed
issue where activity feed was showing a change when profiles didn't
actually change.
For #25244
The root cause of the bug was using `NULLIF` instead of the correct
`IFNULL` MySQL command. (Seriously, who named these?).
Also, refactored
[batchSetMDMAppleDeclarations](https://github.com/fleetdm/fleet/blob/victor/25244-batchsetMDMprofile/server/datastore/mysql/apple_mdm.go#L4224)
method to speed up future changes/fixes.
# Checklist for submitter
- [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/Committing-Changes.md#changes-files)
for more information.
- [x] Added/updated automated tests -- Actually, fixed test that was
already failing
- [x] Manual QA for all new/changed functionality
Changing this to reduce confusion moving forward. It didn't cause any
issues because fleetd package always passes this flag to the configured
URL (so the default value is never used when running orbit in fleetd).
"tuf.fleetctl.com" in tooling will be modified (copied) soon.
## For #24421
- Filter out self-service path in this case
- Remove a number of redundant states by having local variables depend
on useQuery's internal state
- [x] Changes file added for user-visible changes in `changes/`
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
For #23529, #23530.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [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/Committing-Changes.md#changes-files)
for more information.
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] If database migrations are included, checked table schema to
confirm autoupdate
- For database migrations:
- [x] Checked schema for all modified table for columns that will
auto-update timestamps during migration.
- [x] Confirmed that updating the timestamps is acceptable, and will not
cause unwanted side effects.
- [x] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
- [x] Added/updated automated tests
- [x] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
> No issue, just something I noticed
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Manual QA for all new/changed functionality
Changes:
- Updated the `build-static-content` script to add the merged osquery
schema JSON to the website's `builtStaticContent` configuration
- Updated view-query-generator to have a badConfig exit that is used if
the website has an invalid `builtStaticContent.schemaTables`
configuration
- Updated `get-llm-generated-sql` to use the
`builtStaticContent.schemaTables` instead of attempting to use
`sails.helpers.getExtendedOsquerySchema()` (Which does not work as
intended when run in a production environment.)
> For #25084
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Tim Lee <timlee@fleetdm.com>
For #24816
Fix issue when identical MDM commands are sent twice to the same device
when replica DB is being used.
Root cause was that ctxdb.RequirePrimary wasn't used correctly, and
proper test was missing.
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
- [x] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
## For #25320
- [x] Added/updated automated tests
- [ ] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
> For #24873
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [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/Committing-Changes.md#changes-files)
for more information.
- [x] Added/updated automated tests
- [x] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Ian Littman <iansltx@gmail.com>
Haven't done full research yet on why this is, but my guess is that if
an install fails we don't know at what stage it failed, so running an
uninstall script would potentially just break things further. Putting
the trigger on post-install means that it's opt-in (we don't populate
post-install scripts by default) and we're uninstalling from a
relatively known state (the installer didn't error).
I'll get an issue filed tomorrow to make sure that this remains the
desired behavior, or if not then when we change this (e.g. when
implementing patching flows), but might as well fix docs in the interim
to be clear about what we're doing.
Co-authored-by: Drew Baker <89049099+Drew-P-drawers@users.noreply.github.com>
> No issue, just something I noticed while reading docs
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Manual QA for all new/changed functionality
George Karr