<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#40724
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
## Testing
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#41391
# Details
This PR updates front-end API calls to use new URLs and API params, so
that the front end doesn't cause deprecation warnings to appear on the
server.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] 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.
n/a, should not be user-visible
## Testing
- [X] Added/updated automated tests
- [ ] QA'd all new/changed functionality manually
The biggest risk here is not that we missed a spot that still causes a
deprecation warning, but that we might inadvertently make a change that
breaks the front end, for instance by sending `fleet_id` to a function
that drops it silently and thus sends no ID to the server. Fortunately
we use TypeScript in virtually every place affected by these changes, so
the code would not compile if there were mismatches between the API
expectation and what we're sending. Still, spot checking as many places
as possible both for deprecation-warning leaks and loss of functionality
is important.
## Summary by CodeRabbit
* **Refactor**
* Updated API nomenclature across the application to use "fleets"
instead of "teams" and "reports" instead of "queries" in endpoint paths
and request/response payloads.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** For #33391
## Testing
- [X] Added/updated automated tests
there's a number of tests for this, if they still pass we're in good
shape
- [X] QA'd all new/changed functionality manually
I tested the front-end successfully, and saw an auto-update go through
on an ipad. Also verified that the activity metadata is correct.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** For #35459
# Details
This PR adds front-end tests for:
* `<SoftwareSummaryCard>`
* Smoke-test of basic functionality (showing the software title and
type, showing an icon)
* Action dropdown options for various kinds of software
* `<EditAutoUpdateConfigModal>`
* Options for auto-updates (enable button, maintenance window
validation)
* Targets ("All hosts" and "Custom" values and validation)
* Form submission (ensuring the API receives the expected payload for
various permutations of the form)
The `<TargetLabelSelector>` component has its own tests so we don't go
through it thoroughly here, just integration tests with the new
component. Conversely the `<SoftwareDetailsSummary>` component _doesn't_
have its own tests, and could use some, but in this instance we're just
concerned with how it integrates with the software summary card (that
is, how the passed-in software title affects the Actions dropdown).
## Testing
- [X] Added/updated automated tests
---------
Co-authored-by: Gabriel Hernandez <ghernandez345@gmail.com>
Co-authored-by: Nico <32375741+nulmete@users.noreply.github.com>
