## Summary
**What** — What changes are introduced in this PR?
- Fix validators of delete item action for exchanges and claims to not include filter fields (their routes don't use these filters, and it doesn't make sense to have them)
- Fix query parameter type argument of the create reservation route to the correct HTTP type.
- Fix the HTTP type used for listing products and shipping options in the storefront to not include the `with_deleted` (It's also not supported by their validators)
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
## Summary
**What** — What changes are introduced in this PR?
This PR is part of a series of PRs to fix HTTP and request type arguments.
This is the last PR in the series. It includes a changeset for the changes made.
**Why** — Why are these changes relevant or necessary?
These types impact the outputted OAS which we show on the API reference. By fixing up the types, we ensure accurate request parameters in the API reference.
**How** — How have these changes been implemented?
Made changes to HTTP types and request type arguments
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
-
---
## Examples
-
---
## Checklist
Please ensure the following before requesting a review:
- [ ] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
-
## Summary
**What** — What changes are introduced in this PR?
Add a method in the Tax Module's servie to retrieve a provider by its ID.
**Why** — Why are these changes relevant or necessary?
The Tax Module Provider could be used for use cases other than calculating tax lines. For example, Avalara supports importing products to manage product-specific taxes. However, it's not possible right now to listen to the `product.created` event and create the product in Avalara with its provider. Instead, you'll have to create a separate module that also connects to Avalara and resolve it in the subsriber.
This also matches the pattern in the Analytics Module, which allows retrieving the underlying provider.
**How** — How have these changes been implemented?
Add a `getProvider` method to the Tax Module's service and its interface.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Added integration test for the method.
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
const avalaraProvider = taxModuleService.getProvider("tp_avalara_avalara")
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [x] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
When starting the Medusa application i see the following in the console:
```
update-order-tax-lines: "when" name should be defined. A random one will be assigned to it, which is not recommended for production.
({ input }) => {
return input.item_ids?.length > 0;
}
update-order-tax-lines: "when" name should be defined. A random one will be assigned to it, which is not recommended for production.
({ input }) => {
return input.shipping_method_ids?.length > 0;
}
```
This PR fixes the issue by passing a step name as a first parameter to the `when` usages in `updateOrderTaxLinesWorkflow`