What
This commit introduces the `stockLocationsCreated` hook to the `createStockLocationsWorkflow`.
Why
The hook was missing and necessary to improve the workflow's extensibility.
How
Added the `stockLocationsCreated` hook and updated related logic within the workflow.
Testing
1. Create new medusa project via create-medusa-app
2. Connect this custom branch of medusa to it
3. Create `src/workflows/hooks/stock-locations-created.ts` file with the following content:
```
import { createStockLocationsWorkflow } from "@medusajs/medusa/core-flows"
createStockLocationsWorkflow.hooks.stockLocationsCreated(
(async ({ stockLocations, additional_data }, { container }) => {
console.log({stockLocations})
})
)
```
4. Create new admin account and create there a new stock location
5. The log should be displayed in terminal
**What**
Currently, we are potentially providing an array of selector/data leading to fetching data sequentially before running on update which will fetch data again in batch and perform the update. Now we can pass the data directly which includes the id already and only perform one bulk fetch + one bulk update.
This pr also include a fix on the inventory validation, currently, only the item to update inventory is being checked, with this pr we also check the inventory for the items that needs to be created
**What**
Some steps were calling the modules even when nothing was needed which for some operations would create transaction for nothing leading to extra execution time that add up very quickly on cloud network
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
What:
* Not all Cart operations need a full refresh updating items. This PR introduces a flag to force the refresh for special ocasions, like updating the Cart's region, or transfering the Cart to another customer. For all other flows it will update only promotions, taxes and payment collection if needed.
* fix(core-flows): Allow adding shipping methods through order edits
* fix(core-flows): Allow adding shipping methods through order edits
* update test description
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- add `insufficient_inventory` flag when listing shipping options for a cart
- add `enabled_in_store` flag when creating/editing pickup options
**What**
- update the create and edit shipping option flows to support pickup (shipping) option
- modify "mark as delivered" for pickup case
---
CLOSES CMRC-906 CMRC-907
**What**
- if a cart contains variants that share inventory items, reservation of the item would fail also causing complete cart to fail
- include `completed_at` when compensating cart update
- account for multiple reservations of the same item when creating the locking key
---
CLOSES SUP-587
This PR adds a couple new statuses to the payment collection and payment webhook results. The payment collection will now be marked as "completed" once the captured amount is the full amount of the payment collection.
There are several things left to improve the payment setup, so non-happy-path cases are handled correctly.
1. Currently the payment session and payment models serve a very similar purpose. Part of the information is found on one, and the other part on the other model, without any clear reason for doing so. We can simplify the payment module and the data models simply by merging the two.
2. We need to handle failures more gracefully, such as setting the payment session status to failed when such a webhook comes in.
3. We should convert the payment collection status and the different amounts to calculated fields from the payment session, captures, and refunds, as they can easily be a source of inconsistencies.
