Fixes#13625
---
> [!NOTE]
> Ensure `reserved_quantity` is adjusted when deleting reservation items via `deleteReservationItems`, with new integration tests covering deletion and inventory updates.
>
> - **Inventory Module Service (`packages/modules/inventory/src/services/inventory-module.ts`)**:
> - Add `deleteReservationItems` API (and transactional `_` variant) that hard-deletes reservations, then updates related inventory levels via `adjustInventoryLevelsForReservationsDeletion`.
> - Wire through event emission/manager decorators consistent with existing patterns.
> - **Integration Tests (`packages/modules/inventory/integration-tests/__tests__/inventory-module-service.spec.ts`)**:
> - Add tests for `deleteReservationItems` to verify deletion by id and `reserved_quantity` adjustments on inventory levels.
> - Minor import update to include `ReservationItemDTO`.
> - **Changeset**:
> - Patch release note for `@medusajs/inventory` documenting the fix.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ac6641a9ec9543115504407f708f81bd427c3444. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Closes#13163
I have a few questions about expected behaviour, since this currently breaks some tests:
- Many tests use the productModule to create products, with default status == "draft", and use the addToCart workflow which now throws. Should I change all breaking tests to specify status == "published" whne creating the product? The alternative would be to check the status in the store API route before the workflow but 1. it would be an extra query and 2. the addToCart workflow is only used in the store currently, and even if it was to be used admin-side, it still doesn't make sense to add a draft product to cart
- After this PR an unpublished product would give the same error as a variant that doesn't exist. While imho this is correct, the thrown error (for both) is "Items do not have a price" which doesn't make much sense(i believe the workflows goes through with an empty variants list and then errors at the price check point). Should I throw a different error when a variant doesn't exists/isn't published?
---
> [!NOTE]
> Enforces that only variants from published products can be added to carts, adds status fetching, refines errors, and updates tests to use ProductStatus.PUBLISHED.
>
> - **Core Flows**:
> - addToCart: Validate variants exist and belong to `product.status = PUBLISHED`; throw clear `INVALID_DATA` when not found/unpublished.
> - Data fetching: Include `product.status` in `cart` and `order` variant field selections.
> - **Tests/Fixtures**:
> - Update integration tests to set `status: ProductStatus.PUBLISHED` when creating products and import `ProductStatus` where needed.
> - Add cases for unpublished products and non-existent variants producing the new error message.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ca72532e957964d2d8e6bcecbb0905054c677ded. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Currently the plugin:db:generate command panics if one of the modules doesn't define any data models. This makes it impossible to generate migrations if you have a mix of modules with and without data models.
I added a simple check to skip these modules when creating the migrations.
Steps to repro:
```
npx create-medusa-app --plugin
cd my-medusa-plugin
# create a module with an empty service and no data models
npx medusa db:plugin:generate
```
Full error:
```
info: Generating migrations...
info: Generating migrations for module postmarkModuleService...
info: ----------------------------------------------------------------------------
error: defineMikroOrmCliConfig failed with: entities is required
Error: defineMikroOrmCliConfig failed with: entities is required
at defineMikroOrmCliConfig (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/utils/src/modules-sdk/mikro-orm-cli-config-builder.ts:41:11)
at generateMigrations (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/medusa/src/commands/plugin/db/generate.ts:124:26)
at main (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/medusa/src/commands/plugin/db/generate.ts:49:11)
at processTicksAndRejections (node:internal/process/task_queues:105:5)
```
I didnt bother with writing an issue since I had the fix ready and it's very small, but lmk if I should in the future
RESOLVES CORE-1153
**What**
- This pr mainly lay the foundation the caching layer. It comes with a modules (built in memory cache) and a redis provider.
- Apply caching to few touch point to test
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
**What**
The context reference is being mutated by the repository leading to an empty context. Also, the filter is built from the pricing context instead of pricing context -> context leading to always fetch all preferences all the time
PARTIALLY RESOLVES CORE-1156
**What**
Improve upsertWithReplace to batch as much as possible what can be batched. Performance of this method will be much greater specially for cases with maybe entities and batch (e.g we seen many cases where they bulk product with hundreds variants and options etc)
for example let take the following object:
- entity 1
- entity 2 []
- entity 3 []
- entity 2 []
- entity 3 []
here all entity 3 will be batched and all entity 2 will be batched
I ve also added a pretty detail test that check all the stage and what is batched or not with many comments so that it is less harder to consume and remember in the future
Also includes:
- mikro orm upgade (issues found and fixes)
- order module hooks fixes
**NOTE**
It was easier for now to do this instead of rewriting the different areas where it is being used, also, maybe it means that we will have closer performance to what we would expect to have natively
**NOTE 2**
Also fix the fact that integration tests of the core packages never ran 😂
RESOLVES CORE-1204
**What**
- Fix wrong price tier when multiple items are targetting the same variant
- fix type import from the wrong package
**Notes**
If you are struggling navigating the changes, you can focus on the following files:
```
integration-tests/http/__tests__/cart/store/cart.spec.ts
integration-tests/modules/__tests__/cart/store/cart.workflows.spec.ts
packages/core/core-flows/src/cart/steps/get-promotion-codes-to-apply.ts
packages/core/core-flows/src/cart/steps/get-variant-price-sets.ts
packages/core/core-flows/src/cart/workflows/add-to-cart.ts
packages/core/core-flows/src/cart/workflows/create-carts.ts
packages/core/core-flows/src/cart/workflows/get-variants-and-items-with-prices.ts
packages/core/core-flows/src/cart/workflows/refresh-cart-items.ts
packages/core/core-flows/src/order/workflows/add-line-items.ts
packages/core/core-flows/src/order/workflows/create-order.ts
```
In the order details page, clicking the copy button for customer phone number was incorrectly copying the email address instead of the phone number.
Co-authored-by: William Bouchard <46496014+willbouch@users.noreply.github.com>
**What**
- add InfiniteList on location selection for inventory level -> fixes issue with location pagination
- fix removal of location level for an inventory item
- refresh the levels table when locations are updated
- add search input for filtering locations
---
CLOSES CORE-1208
**What**
- a promotion couldn't be added to a campaign without a currency budget (on promotion details screen)
- fix fetching campaigns pagination issue
- move select to Combobox
- fix currency restriction and move warning description to the label hint
CLOSES CORE-1209
This PR just adds the stuff necessary to support refund reasons in the dashboard. It adds the option in the settings tab and allows viewing, creating, editing and deleting refund reasons. I hate to open such a big PR but most of it is copy pasted from the return reasons. Major difference is only the fact that refund reasons don't have a `value` field
* fix: add direction attribute to components and adjust styles for RTL support
* fix(data-grid): comment it out
* Added useDocumentDirection hook
* refactor: Integrate useDocumentDirection hook
* refactor: Standardize direction prop usage across components
* resolve
* fix: resolve build errors
* fix : remove unused useDocument
* Apply RTL styles for some components
* Create smooth-gorillas-hide.md
* refactor: update some styles for RTL support
---------
Co-authored-by: William Bouchard <46496014+willbouch@users.noreply.github.com>
