Related to: #20296
Changes:
- Added `ee/bulk-operations-dashboard`, a Sails.js app that lets users
manage configuration profiles and scripts across multiple teams on a
Fleet instance.
- Added a Github workflow to deploy the app to Heroku
- Added a Github workflow to test changes to the bulk operations
dashboard.
Changes:
- Updated save-questionnaire-progress to send a formatted string of a
user's start questionnaire responses to the
update-or-create-contact-and-account helper
- Updated the update-or-create-contact-and-account helper to set
getStartedResponses on contact records.
> Related issue: #21475
# 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 tests
- [x] Manual QA for all new/changed functionality
Related to: https://github.com/fleetdm/confidential/issues/7339
Changes:
- Updated `save-questionnaire-progress` to return the user's selected
`primaryBuyingSituation`
- Updated the /start flow to update data in Segment
- Removed the border on the /start flow images that I mistakenly added.
Closes: #21417Closes: #21413Closes: #21378
Changes:
- Updated save-questionnaire-progress to return the user's current
psychological stage when a user submits a step of the /start
questionnaire
- Updated the /start questionnaire to display an image that changes as
the user's psychological stage progresses.
- Updated the first step of the /start questionnaire and gave users the
ability to go back to the first step.
- Added an option for Linux to the "what do you manage" question that is
asked to MDM-focused users
- Added a step for MDM-focused users filling out the /start
questionnaire
- Updated the /start CTA to show different images based on psychological
stage and to be visible to users who have not purchased a self-service
license
main task: #19857
subtask: #21392
- For GET /api/v1/fleet/vulnerabilities/{cve} endpoint, added validation
of CVE format, and added a 204 response. The 204 response indicates that
the vulnerability is known to Fleet but not present on any hosts.
- Removed the previous known_vulnerability field implementation
# 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 tests
- [x] Manual QA for all new/changed functionality
#21073
- Deleted iOS/iPadOS host will continue to report to Fleet as long as
host is in Apple Business Manager (ABM).
- Refetching an offline iOS/iPadOS host will not add new MDM commands to
the queue if previous refetch has not completed yet.
Video demo:
https://www.loom.com/share/2f7ecb22e1924d4cbbbdd7dd297439ef?sid=dbfe1939-cb46-47ca-a7a8-84965ed68a7e
I considered `nano_command_results` but could not think of an efficient
way to use `nano_command_results` to determine if refetch was already
done. The problem is that we're overloading `command_uuid` to include
the `REFETCH` identifier. So we can't simply add an index on `(uuid,
command_uuid, updated_at)`. We need to do a partial text match on
`command_uuid` which then requires a full scan of the matching
`updated_at` timestamps. It feels like a search like this could blow up
for a large `nano_enrollment_queue` and `nano_command_results` table.
# 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 tests
- [x] If database migrations are included, checked table schema to
confirm autoupdate
- For database migrations:
- [x] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
- [x] Manual QA for all new/changed functionality
This is an easy way to debug the various vulnerabilities ETLs that we'd
normally execute as an in-app cron. I used this over the weekend to test
#21242.
# Checklist for submitter
- [x] Manual QA for all new/changed functionality
moving away from calling people "leads", it's weird
this continues the effort of making it so that leads are more like a:
"dear fleeties, you have to do something"
Now, lead sources are effectively GA conversions, and will eventually
change to just be auto-created stage0 opportunities, and even then only
for booked meetings where there's work that a fleetie needs to do to
make sure and prepare a useful demo for the folks on the other end, so
they can present Fleet internally while spending as little time talking
to us as possible.
So that's the end of lead sources.
Whereas compare w/ user actions, which are now captured as either
contact creation (contact source), contact psychological progress (most
recent psystage change reason), or opportunity creation (opportunity
source).
- Moved "Compile feedback" step to before "Request CEO interview"
- Fixed typos
FYI @ireedy
---------
Co-authored-by: Sam Pfluger <108141731+Sampfluger88@users.noreply.github.com>
#19561
In Fleet GUI, downloading a software installer package now shows the
browser's built-in progress bar.
New API endpoints: https://github.com/fleetdm/fleet/pull/21346
# Checklist for submitter
<!-- 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 tests
- [x] Manual QA for all new/changed functionality
#20571
## Summary of changes
We have a few moving parts in fleetctl land (`fleetdm/wix` is used to
build `msi`s and `fleetdm/bomutils` is used to build `pkg`s, and
`fleetdm/fleetctl` can be used to build packages using docker, no need
for fleetctl executable):
```mermaid
graph LR
fleetctl_exec[fleetctl<br>executable];
wix_image[fleetdm/wix<br>docker image];
bomutils_image[fleetdm/bomutils<br>docker image];
fleetctl_image[fleetdm/fleetctl<br>docker image];
fleetctl_exec -- uses --> wix_image;
fleetctl_image -- COPY dependencies<br>FROM --> wix_image;
fleetctl_exec -- uses --> bomutils_image;
fleetctl_image -- COPY dependencies<br>FROM --> bomutils_image;
```
So, we'll need to update the three images: `fleetdm/bomutils`,
`fleetdm/wix` & `fleetdm/fleetctl`.
- `tools/bomutils-docker/Dockerfile`, `tools/wix-docker/Dockerfile` and
`tools/fleetctl-docker/Dockerfile`: Updating the base image to fix the
CRITICAL vulnerabilities.
- Modified existing+unused
`.github/workflows/build-and-check-fleetctl-docker-and-deps.yml` to run
every day to check for CRITICAL vulnerabilities in `fleetdm/wix`,
`fleetdm/bomutils` and `fleetdm/fleetctl`.
- `.github/workflows/goreleaser-fleetctl-docker-deps.yaml`:
`fleetdm/bomutils` and `fleetdm/wix` were pushed manually a few years
ago (most likely by Zach), so I've added a new action to release them
when we have changes to release (like now). It will basically release
`fleetctl/bomutils` and `fleetdm/wix` when pushing a tag of the form
`fleetctl-docker-deps-*` (we'll need to protect such tag prefix).
- Changes in `.github/workflows/test-native-tooling-packaging.yml` to
build `fleetdm/bomutils` and `fleetdm/wix` for `fleetdm/fleetctl` to use
them instead of the ones in docker hub.
--
Build before upgrading `debian:stable-slim`:
https://github.com/fleetdm/fleet/actions/runs/10255391418/job/28372231837
Build after upgrading `debian:stable-slim`:
https://github.com/fleetdm/fleet/actions/runs/10255550034
- [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] Manual QA for all new/changed functionality
## Issue
Story #19099
Subtask #20706
## Description
- Additions to Software > Software tab to filter software and versions
by vulnerable, known exploit, and CVSS score
- Includes a new "Add filters" button which has dynamic tooltip and
button text
- New responsive design to the table header controls
- New modal to customize vulnerability filters
- Handles edge case where user types in a custom CVSS score in URL
## TODO list
- [x] Design, confirm and build empty states
- [x] search bar is showing on empty state, fix this
- [x] Disabled state color for dropdown placeholder text
- [x] Add tests to the modal
- [ ] Test with API when API is ready (good flow to check, choose from
dropdown, then toggle versions on)
## Screen recording
TODO
# 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] Added/updated tests
- [ ] Manual QA for all new/changed functionality
Changes:
- Updated the `update-or-create-contact-and-account` helper to set a
"Contact source" on new contact records created.
- Updated everywhere where a lead source was being set to instead set a
contact source
Redirected the link for "Learn how to use Fleet" from local preview to
go to [/guides/queries](https://fleetdm.com/guides/queries) since the
information in "Learn how to use Fleet" is redundant.
This ensures `#help-engineering` is notified when a dogfood deploy is in
progress. It helps set people's expectations about what's going on while
the server is temporarily down.
