Add documentation for enabling bootstrap packages during MDM migration.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#39634
## Changes
Fixes incorrect YAML example in
`docs/Configuration/agent-configuration.md` where `command_line_flags`
was shown nested under `config:` instead of at the top level.
**File changed:** `docs/Configuration/agent-configuration.md`
## What was wrong
The example in the `## config` section showed `command_line_flags`
indented under `config:`:
```yaml
config:
options:
distributed_interval: 3
...
command_line_flags: # ❌ WRONG - nested under config
verbose: true
...
decorators:
...
```
This is incorrect and causes the following error when applied via
`fleetctl apply` for team YAML files:
```
Error: applying teams: POST /api/latest/fleet/spec/teams received status 400 Bad Request:
"command_line_flags" should be part of the top level object
```
## Correct placement
Per the original implementation in
[#7377](https://github.com/fleetdm/fleet/issues/7377),
`command_line_flags` must be a **top-level key** under `agent_options`,
at the same level as `config:`:
```yaml
config:
options:
distributed_interval: 3
...
decorators:
...
yara:
...
command_line_flags: # ✅ CORRECT - top level, sibling of config
verbose: true
...
```
This is consistent with:
- The [Configuration files
docs](https://fleetdm.com/docs/configuration/configuration-files) which
correctly show `command_line_flags: {}` at the top level
- Issue #7377 which states: *"The overrides setting does not accommodate
command_line_flags, which is why it is only allowed at the top-level
(and not inside config or every override)"*
- The overrides section of the same page which notes: *"the
command_line_flags key is not supported in the overrides"*
## Related issues
- Closes: https://github.com/fleetdm/confidential/issues/14206
- Closes: https://github.com/fleetdm/confidential/issues/14207
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Rephrase instructions for creating API-only users for clarity.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#35696
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
- Document which keys are supported on which platforms.
- Separate feature request to come up with a cross-platform name for
`macos_setup` is here: https://github.com/fleetdm/fleet/issues/33059
**Related issue:** Resolves
[34890](https://github.com/fleetdm/fleet/issues/34890)
# Checklist for submitter
- [X] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
## Testing
- [X] Added/updated automated tests
- [X] QA'd all new/changed functionality manually
## New Fleet configuration settings
Looking at other log destinations, I couldn't find anything relevant in
GitOps. Please let me know if I missed something, however.
## fleetd/orbit/Fleet Desktop
I've tested this on both Linux and MacOS.
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
Co-authored-by: nulmete <nicoulmete1@gmail.com>
This pull request adds support for two new software categories,
"Security" and "Utilities", across the application. The changes ensure
these categories are available in the database, frontend type
definitions, UI elements, documentation, and are fully tested in both
migration and integration test suites.
**Database and Migration Updates:**
* Added "Security" and "Utilities" entries to the `software_categories`
table and updated initial data in `schema.sql`.
* Introduced a new migration
(`20251210000000_AddSecurityAndUtilitiesCategories.go`) to insert/remove
these categories, with an accompanying test to verify migration
behavior.
[[1]](diffhunk://#diff-57da59e73fff8f2ffccd167299027899614281c591b79715b7000bed0e9d8516R1-R31)
[[2]](diffhunk://#diff-5e6db34b45e83ec5cf2b9cb41e4bfd4ee934f456dd9c0ae4313a448d39319c72R1-R28)
**Frontend and Documentation Updates:**
* Updated the `SoftwareCategory` type and category lists to include
"Security" and "Utilities", ensuring they appear in the UI and are
selectable.
[[1]](diffhunk://#diff-4297079e443d574eb530c70ef48de3cab80e56f783c7b395d58c31c29be6bb0eL77-R79)
[[2]](diffhunk://#diff-405dcd4f0bd6881e4b20a75212467d13c143ddc486b5c9d29ed9035033c32361R25-R26)
* Added documentation for the new categories in `yaml-files.md`.
**Testing Enhancements:**
* Added and updated tests to verify the new categories are displayed and
handled correctly in both frontend and backend integration tests.
[[1]](diffhunk://#diff-d151ee297fdaf54f8ea7027bc46de12247c43406b464265f24ade5a49cb19e49R210-R211)
[[2]](diffhunk://#diff-bbd0c5a6bc2f9a24e633031d4c6a3f5b0be7cbfe78ef1b56cdf9a7a2c32e21e2R19358-R19365)
[[3]](diffhunk://#diff-2bd8ca2ddaad7aac0c438a2afd76a26872378249f757c9c81a31005d0e57cf1fR18447-R18460)
Resolves#36909.
# 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.
## Testing
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
Proposing that we update this language to match what actually happens if
you add a VPP app using an adamID (all platforms with that adamID are
added, along with any settings like self service categories, setup
experience, labels, etc.)
Noah Talerman