Prior to 4.35.0, some rows in the scheduled_query table might have a
`NULL` value due to a race condition with database replicas and the way
`ds.EnsureGlobalPack` and `ApplyPackSpecs` work together.
This is no longer the case, but some databases are left in weird states,
which were not accounted by this migration.
Chaning the migration in-place because that's the approach we took in
previous migrations with similar problems.
in previous releases we weren't setting the value of description in some
of our `INSERT ON DUPLICATE KEY UPDATE` clauses, which caused some
queries to fail.
we could additionally add a migration to set all NULL values to '' and
make the column non-nullable, but as a first step I'm fixing this at the
application logic level.
related to: https://github.com/fleetdm/fleet/issues/12923
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Added/updated tests
- [x] Manual QA for all new/changed functionality
1. Cached results of `svc.ds.Team`
2. Cached results of `svc.ds.ListQueries` too for scheduled queries
only.
3. Do not load aggregated stats on `svc.ds.ListQueries` insde
`GetClientConfig`
this helps consumer of the datastore method handle the not found
scenario better and ensures we always return a 4xx code by default if we
can't find a matching team.
seems like calls to this method were special-cased everywhere except in
the apply user roles endpoint, where we returned a `500` status code if
we couldn't find a team.
Related to #12608, this automatically sets the
`DeferForceAtUserLoginMaxBypassAttempts` property to `1` on the
FileVault profile that's generated by Fleet.
This changeset also includes a migration to modify old FileVault
profiles that already exist in the database, and by virtue of that a
`InstallProfile` command will be issued to hosts that already have FV
enabled. During testing we found:
1. This doesn't affect users with FV already installed, they silently
get the profile updated without any changes.
2. Since the profile needs to be re-delivered, it'll go through the full
"pending" -> "verifying" -> "verified" cycle.
This relates to #12263
# 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/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#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 tests
---------
Co-authored-by: Roberto Dip <me@roperzh.com>
Issue #12261
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [ ] Documented any API changes (docs/Using-Fleet/REST-API.md or
docs/Contributing/API-for-contributors.md)
- [ ] Documented any permissions changes
- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [ ] Added support on fleet's osquery simulator `cmd/osquery-perf` for
new osquery data ingestion features.
- [ ] Added/updated tests
- [ ] Manual QA for all new/changed functionality
- For Orbit and Fleet Desktop changes:
- [ ] Manual QA must be performed in the three main OSs, macOS, Windows
and Linux.
- [ ] Auto-update manual QA, from released version of component to new
version (see [tools/tuf/test](../tools/tuf/test/README.md)).
