This PR closes https://github.com/fleetdm/fleet/issues/21108
@noahtalerman, I double-checked all redirects, and they are working.
Clicking through the URLs in [this
spreadsheet](https://docs.google.com/spreadsheets/d/1djVynIMuJK4pT5ziJW12CluVqcaoxxnCLaBO3VXfAt4/edit?usp=sharing)
is a pretty quick way to go through them all. Note that "Audit logs" and
"Understanding host vitals" redirect to the contributor docs on GitHub,
so they will throw a 404 until this is merged.
Some new guides benefitted from a name change, so they make more sense
as stand-alone guides, and also so that we don't have to mess around
with more redirects later. Those name changes followed [this
convention](https://fleetdm.com/handbook/company/communications#headings-and-titles),
which was recently documented in the handbook.
Have fun!
---------
Co-authored-by: Eric <eashaw@sailsjs.com>
Co-authored-by: Noah Talerman <noahtal@umich.edu>
- Only one of either `labels_include_all` or `labels_exclude_any` can be
included in the request.
- Add missing labels `id` in `GET /configuration_profiles` and `GET
/configuration_profiles/:uuid`
- Mark new API endpoints or API endpoints that were changed as part of
Fleet's first app management feature (#14921) as experimental.
- Call out what is experimental exactly (the endpoint or new keys/values) and
point to changes
For #19540
Just added the same "exclude_software" functionality that exists in "get
hosts" to the "get host by identifier" function.
- [ ] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [ ] Manual QA for all new/changed functionality
Follow up from https://github.com/fleetdm/fleet/pull/20109: there were a
few descriptions that just said "body" because of some table rows with
an extra column I missed when merging in recent updates.
Since the "Modify config" parameters are mostly a bunch of different
objects, it's a bit unwieldy to document in one table. Trying out a new
format to see if it feels like the right way to document nested objects
in API parameters.
API changes for the "Get unlock PIN immediately after locking macOS
host" story (https://github.com/fleetdm/fleet/issues/19545)
---------
Co-authored-by: Victor Lyuboslavsky <victor.lyuboslavsky@gmail.com>
Noticed several places where the structure of
`mdm.macos_settings.custom_settings` and
`mdm.windows_settings.custom_settings` didn't match the example response
for "Get configuration" (which I think is the most up-to-date).
(Will follow up and update the parameter descriptions for
`mdm.macos_settings.custom_settings`/`mdm.windows_settings.custom_settings`
to clarify they're objects with `path` and `labels` once
https://github.com/fleetdm/fleet/pull/19424 is merged.)
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
`server_settings.enable_analytics` was only documented in the "Get
configuration" endpoint and nowhere else. Added to "Modify
configuration" params and example response.
