**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**
Align the index engine API to be similar to the Query API
## Example
```ts
// Benefit from the same level of typing like the remote query
const { data, metadata } = await indexEngine.query<'product'>({
fields: [
"product.*",
"product.variants.*",
"product.variants.prices.*",
],
filters: {
product: {
variants: {
prices: {
amount: { $gt: 50 },
},
},
},
},
pagination: {
order: {
product: {
variants: {
prices: {
amount: "DESC",
},
},
},
},
},
})
```
what:
- when an empty array is passed to the workflow, it attempts to delete all inventory locations. This PR adds a conditional to prevent it from happening.
RESOLVES CC-477
Fixes https://github.com/medusajs/medusa/issues/9154
**What**
- on cart completion, when creating reservations, use line item id instead of cart item id
- NOTE: inventory reservation is now done after we create the order
---
FIXES CC-448
* wip
* more work
* working on stuff
* more
* fix test
* remove incorrect test
* fix test
* fix: Only allow deletion of yourself
* remove redundant tests
* wip
* more work
* wip
* more work
* wrap up first iteration
* work on new approach
* more work
* move middleware func to route
* cleanup
* more work
* wrap up
* more work
* fix workflow
* minor tweaks
* finalize
* Use JWT secret instead
what:
I've added some specs and comments in the specs for where I think totals are incorrect.
Lets get this test merged in as the status quo and proceed to fix these issues one by one.
Additionally, this also removes the temporary_difference as its not something we use.
RESOLVES CC-346
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
RESOLVES FRMW-2110
RESOLVES FRMW-2095
**What**
- Fix notification module to not retain transactions open while sending notification
- Add support for notification status [success, pending, failure]