**What**
- Removes broken cart retrieval step `retrieveWithCartLinks` in favor of `useRemoteQueryStep` in `updateTaxLinesWorkflows`
**Why**
- Filters variables in the step were passed with an incorrect shape
- I removed the step, since it's only used once and the behavior is identical to the generic remote query step
**Note**
- Because the filters were passed incorrectly, the, now-removed, step has always returned the first cart in the database. As a result all tax calculations so far have been based on whatever the shape of that cart has. It basically ignores all input to this workflow
**What**
- Fixes an issue where the admin dashboard would send region prices for deleted regions.
- Also, includes the implementation for `GET /admin/shipping-options/:id` and its corresponding SDK function.
**Why**
- When a region price for a deleted region was sent to the backend it would result in the insert hitting a not null constraint on the currency_code for prices. To avoid this the dashboard should not send region prices for deleted regions.
**Additional context**
- Prices for deleted regions should ideally not be returned when fetching shipping option prices. However, we don't yet have a mechanism for cleaning up region prices after a region is deleted.
Fixes CC-540
What
- Require `code` on Tax Rates
- Update dashboard to account for non-nullable code on Tax Rates
- Include `automatic_taxes` in API Route response
Closes CC-524 CC-525
**What**
- Adds a step to `updateShippingOptionsWorkflow` and `createShippingOptionsWorkflow` that validates if the region prices being updated have corresponding regions configured.
**Why**
- Previously, if you tried to send a region price update for a region that had been deleted the backend would throw an error when attempting to insert the region price. The error comes from a not-null constraint in the db, but it is better to validate that the regions we are trying to create prices for exist.
Fixes CC-542
**What**
- Fetches the stock location's details when creating a fulfillment and return fulfillment.
- Passes the data to the fulfillment module, which in turn passes it to the fulfillment provider.
**Why**
- When creating a fulfillment in a multi-location setup the fulfillment provider will need to know where the package is being sent from (so the shipping service can pick it up).
- Previously, we didn't pass anything but the location id to the fulfillment provider. Because the fulfillment provider can't have a dependency on the stock location module this was not sufficient.
- This change ensures there is enough data passed to the fulfillment provider to build integrations properly.
What:
- The time taken to load in sequence is the same as in parallel, and it doesn't create multiple db queries simultaneously when starting each module.
- Rework modules bootstrap (now all dependencies are available from the constructor and cross deps are allowed without any topological sort needed. It also allow improvements in the future)
- First load all modules
- then resolve and register instances
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
- Fix claim / exchange / return extending an order (we previously addressed this in the http types)
- add `@ignore` for all `raw_*` fields to hide them from references.
### types
- Remove `is_internal` and `is_active` from `StoreProductCategory`
- Add missing status, reference, and action enums from `BaseOrderChange` and `BaseOrderChangeAction`
- Remove unused totals from `BaseOrderSummary`.
- Fix references to base types from admin / store types
- Other general fixes
### medusa
- Use HTTP types for create / update return reason routes
- Remove type arguments from the calculate taxes route since it's a `POST` API route but the type argument for the select query parameters only.
- Add `metadata` to the list of cart's fields.
- Add type casting for order previews in response
