## Summary
**What** — What changes are introduced in this PR?
Price lists prices didn't have a dedicated method to query them and instead, relied on being returned as part of price lists. This, however, introduces optimization issues that for price lists with many prices, could cause crashes. The reason being that relations are not paginated and thus, all prices linked to the price list would be returned.
This PR aims to solve this by introducing a dedicated endpoint and avoiding returning the `prices` as part of price lists by default. The idea being that it is up to the user to explicitly express this, which, for small price lists no issues will arise, but for bigger ones, they will easily recognize the performance impact.
**Why** — Why are these changes relevant or necessary?
Users with large enough price lists would have serious performance issues or even crashes when querying the `/admin/price-lists` endpoints. This is also true when navigating to the price list section of the Admin UI since it queries this same endpoints.
**How** — How have these changes been implemented?
- Removed the `prices` relation to be part of the default fields returned by the `/admin/price-lists/` endpoints. User may still request it by passing it in `fields` query param.
- Added new `/admin/price-lists/[id]/prices` GET endpoint to be able to retrieve a price list prices with pagination.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Integration tests.
---
## 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:
- [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
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
The current state of the PR fixes the issue on the price list list and detail component. It still doesn't solve the issue for the following screens: Edit Prices & Add Prices
All the prices are still retrieved from the `/admin/price-lists/` endpoint for these. I want first some feedback before changing it to the new endpoint, since the current DataGrid implementation doesn't support pagination and it seems we are passing a default limit for the products to show there, an arbitrarily large number 9999 and there is also a TODO comment of changing that.
This previous point, though, could be implemented in a later PR, so we can already fix the issue in the price list list and detail pages, so at least for large price lists these screens don't explode and smaller price lists can still have its product prices edited, while only large ones will explode when trying to perform this action. @adrien2p @fPolic thoughts?
closes ENTSUP-265, CORE-1239
ref: https://github.com/medusajs/medusa/pull/14189
**Summary**
This PR extends the translation module to support automatic translation syncing for cart line items based on the cart's locale.
Key changes:
- Added locale field to the Cart model to store the cart's locale preference
- Created new workflow steps:
- getTranslatedLineItemsStep - Translates line items when adding to cart or creating a cart
- updateCartItemsTranslationsStep - Re-translates all cart items when the cart's locale changes
- Integrated translation logic into cart workflows:
- createCartWorkflow - Applies translations to initial line items
- addToCartWorkflow - Applies translations when adding new items
- updateCartWorkflow - Re-translates all items when locale_code is updated
- refreshCartItemsWorkflow - Maintains translations during cart refresh
- Added applyTranslationsToItems utility to map variant/product/type/collection translations to line item fields (title, subtitle, description, etc.)
* chore(): Accept an extra agument 'all-or-nothing' on the migrate command
* Create rich-camels-brush.md
* chore(): Accept an extra agument 'all-or-nothing' on the migrate command
* chore(): Accept an extra agument 'all-or-nothing' on the migrate command
* chore(): Accept an extra agument 'all-or-nothing' on the migrate command
* chore(): fix broken down migrations
* chore(): update changeset
* Allow id field in addresses properties for cart update validator
* Update cart addresses in update step where id is provided, both reference and nested fields
* Add tests
* Add changeset
* Remove unnecessary map step
* Review changes
* feat(): Translation first steps
* feat(): locale middleware
* feat(): readonly links
* feat(): feature flag
* feat(): modules sdk
* feat(): translation module re export
* start adding workflows
* update typings
* update typings
* test(): Add integration tests
* test(): centralize filters preparation
* test(): centralize filters preparation
* remove unnecessary importy
* fix workflows
* Define StoreLocale inside Store Module
* Link definition to extend Store with supported_locales
* store_locale migration
* Add supported_locales handling in Store Module
* Tests
* Accept supported_locales in Store endpoints
* Add locales to js-sdk
* Include locale list and default locale in Store Detail section
* Initialize local namespace in js-sdk
* Add locales route
* Make code primary key of locale table to facilitate upserts
* Add locales routes
* Show locale code as is
* Add list translations api route
* Batch endpoint
* Types
* New batchTranslationsWorkflow and various updates to existent ones
* Edit default locale UI
* WIP
* Apply translation agnostically
* middleware
* Apply translation agnostically
* fix Apply translation agnostically
* apply translations to product list
* Add feature flag
* fetch translations by batches of 250 max
* fix apply
* improve and test util
* apply to product list
* dont manage translations if no locale
* normalize locale
* potential todo
* Protect translations routes with feature flag
* Extract normalize locale util to core/utils
* Normalize locale on write
* Normalize locale for read
* Use feature flag to guard translations UI across the board
* Avoid throwing incorrectly when locale_code not present in partial updates
* move applyTranslations util
* remove old tests
* fix util tests
* fix(): product end points
* cleanup
* update lock
* remove unused var
* cleanup
* fix apply locale
* missing new dep for test utils
* Change entity_type, entity_id to reference, reference_id
* Remove comment
* Avoid registering translations route if ff not enabled
* Prevent registering express handler for disabled route via defineFileConfig
* Add tests
* Add changeset
* Update test
* fix integration tests, module and internals
* Add locale id plus fixed
* Allow to pass array of reference_id
* fix unit tests
* fix link loading
* fix store route
* fix sales channel test
* fix tests
---------
Co-authored-by: Nicolas Gorga <nicogorga11@gmail.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
This PR introduces experimental Hot Module Replacement (HMR) for the Medusa backend, enabling developers to see code changes reflected immediately without restarting the server. This significantly improves the development experience by reducing iteration time.
### Key Features
- Hot reload support for:
- API Routes
- Workflows & Steps
- Scheduled Jobs
- Event Subscribers
- Modules
- IPC-based architecture: The dev server runs in a child process, communicating with the parent watcher via IPC. When HMR fails, the child process is killed and restarted, ensuring
clean resource cleanup.
- Recovery mechanism: Automatically recovers from broken module states without manual intervention.
- Graceful fallback: When HMR cannot handle a change (e.g., medusa-config.ts, .env), the server restarts completely.
### Architecture
```mermaid
flowchart TB
subgraph Parent["develop.ts (File Watcher)"]
W[Watch Files]
end
subgraph Child["start.ts (HTTP Server)"]
R[reloadResources]
R --> MR[ModuleReloader]
R --> WR[WorkflowReloader]
R --> RR[RouteReloader]
R --> SR[SubscriberReloader]
R --> JR[JobReloader]
end
W -->|"hmr-reload"| R
R -->|"hmr-result"| W
```
### How to enable it
Backend HMR is behind a feature flag. Enable it by setting:
```ts
// medusa-config.ts
module.exports = defineConfig({
featureFlags: {
backend_hmr: true
}
})
```
or
```bash
export MEDUSA_FF_BACKEND_HMR=true
```
or
```
// .env
MEDUSA_FF_BACKEND_HMR=true
```
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* fix(): event emitting
* Create rude-queens-deny.md
* fix(): store subscriber should not be constraint
* Update rude-queens-deny.md
* Add tests to prevent regression
* fix(fulfillment): make relationship between SO and SO type M:1
* fix: test and types, remap type id to existing column
* Fix typo
* Fix typo
* chore: update changeset
* fix: typo
---------
Co-authored-by: Nicolas Gorga <62995075+NicolasGorga@users.noreply.github.com>
## Summary
**What** — What changes are introduced in this PR?
Avoid creating reservations when draft order edits are confirmed and rather, create them when the draft order is converted into a regular order.
**Why** — Why are these changes relevant or necessary?
While the order is a draft, creating reservations would potentially block inventory for regular order requests, when the draft represents a non materialized state of a purchase that might never be completed or at a latter point in time.
**How** — How have these changes been implemented?
Removed the reservation creations inside of `confirmDraftOrderEditWorkflow` and instead do it inside `convertDraftOrderWorkflow`
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Added integration tests.
---
## 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:
- [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
- [x] 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.
fixes#13773
closes SUP-2523
## Summary
**What** — What changes are introduced in this PR?
- Add HTTP type for update order API route payload + use it in the JS SDK and API route
- other: add `since` tag
**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.
* feat: carry over promotions toggle on exchanges
* fix: inital flag value, return the flag on preview
* fix: validation of allocation type
* fix: revert client changes
* fix: invert condition
* feat: recompute adjustments when outbound item is updated
* fix: condition again
* fix: display more accurate inbound/outbound totals for exchanges
* fix: make exchanges specs green
* feat: more testing cases
* wip: pr feedback
* fix: use plural for the flag on Admin
* fix: schema test, route refactor
* feat: tooltip
* feat: refactor to use update workflow
* feat: display applied promotion per item on order details, show copy sku on hover
* feat: refactor edits and exchanges to have common flag toggle flow
* fix: delete empty file
* fix: exchange_id param query
* Lock markFulfillmentAsDeliveredWorkflow with fulifllment id
* Lock markOrderFulfillmentAsDeliveredWorkflow by orderId before calling markFulfillmentAsDeliveredWorkflow
* Add changeset
* wip
* add wip
* wip
* reuse action
* finish first draft
* fix tests
* cleanup
* Only compute adjustments when necessary
* Create hot-carrots-look.md
* address comments
* minor tweaks
* fix pay col
* fix test
* wip
* Dwip
* wip
* fix: adjustment typo
* fix: import
* fix: workflow imports
* wip: update test
* feat: upsert versioned adjustments when previewing order
* fix: revert unique codes change
* fix: order spec test with versioning
* wip: save
* feat: make adjustments work for preview and confirm flow, wip base repo filtering of older version adjustments
* fix: missing populate where
* wip: populate where loading versioned adjustments
* fix: filter out older adjustment versions
* temp: comment adjustments in repo
* test: add adjustment if no version
* wip: configure populate where in order base repository
* fix: rm manual filtering
* fix: revert base repo changes
* fix: revert
* fix: use order item version instead of order version
* fix: rm only in test
* fix: update case spec
* fix: remove sceanrio, wip test with draft promotion
* feat: test correct adjustments when disabling promotion
* feat: complex test case
* feat: test consecutive order edits
* feat: 2 promotions test case with a fixed promo
* feat: migrate existing order line item adjustments to order items latest version
* feat: update dep after merge
* wip: load adjustments separatley
* feat: adjustments collections
* fix: spread result, handle related entity case
* fix: update lock
* feat: make sure version is loaded, refactor, handle related entity case
* fix: check fields
* feat: loading adjustments for list and count
* fix: correct items version field
* fix: rm empty array
* fix: wip order modules spec
* fix: order module specs
* feat: preinit items adjustments
* fix: rm only
* fix: rm only
* chore: cleanup
* fix: migration files
* fix: dont change formatting
* fix: core package build
* chore: more cleanup
* fix: item update util
* fix: duplicate import
* fix: refresh adjustments for exchanges (#13992)
* wip: exchange adjustments
* feat: test - receive items
* feat: finish test case
* fix: casing
* fix(draft-orders, core-flows, orders) refresh adjustments for draft orders (#14025)
* wip: draft orders adjustments refresh
* feat: rewrite to use REPLACE action + test
* fix: rm only
* feat: cleanup old REPLACE actions
* feat: cleanup adjustemnts when 0 promotions
* wip: canceling draft order
* fix: make version arg optional
* fix: restore promotion links
* feat: test reverting on cancelation
* fix: address comments in tests
* wip: fix summary on preview
* fix: get pending diff on preview summary from total
* fix: revert pending diff change
---------
Co-authored-by: fPolic <mainacc.polic@gmail.com>
Co-authored-by: Frane Polić <16856471+fPolic@users.noreply.github.com>
## Summary
**What** —
Add a providerData field to notifications
**Why** —
We need the ability to pass dynamic fields to specific providers. E.g. CC and BCC for emails
**How** —
Just adding the field to the model
**Testing** —
Added the field to existing tests
## 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
---
> [!NOTE]
> Adds `provider_data` to notifications (types, workflow input, DB model/migration) and forwards it in the Medusa Cloud Email provider, with tests updated accordingly.
>
> - **Data/Schema**:
> - Add `provider_data` (`jsonb`) to `notification` model and DB via migration `Migration20251121150408` and snapshot update.
> - **Types/DTOs**:
> - Add optional `provider_data` to `CreateNotificationDTO`, `NotificationDTO`, and `ProviderSendNotificationDTO`.
> - **Workflows**:
> - Extend `send-notifications` step input with `provider_data`.
> - **Providers**:
> - Medusa Cloud Email: include `provider_data` in outgoing request payload.
> - **Tests**:
> - Update integration tests to pass and assert `provider_data` propagation.
> - **Changeset**:
> - Patch bumps for `@medusajs/notification`, `@medusajs/core-flows`, `@medusajs/types`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 6f114c75c974a145ef60213637d7c41bc605a0bf. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
## Summary
Updated context passed for each variant when calculating prices so that `region` and `customer` coming from `setPricingContext` are not overriden if provided.
*Please provide answer here*
Otherwise you can't provide your own `region` and `customer` objects with additional information and you are left with the ones we pass as part of the cart object to the workflows that execute the hook.
*Please provide answer here*
Changed the order in which we define the default `region` and `cart` fields, taking their value from the cart, to before the destructured `setPricingContextResult`.
*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:
- [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
- [ ] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
fixes#13990
closes SUP-2647
---
> [!NOTE]
> Adjust pricing context merge order so `setPricingContext`-provided `customer` and `region` are not overridden when calculating variant prices.
>
> - **Core Flows (pricing)**:
> - In `packages/core/core-flows/src/cart/workflows/get-variants-and-items-with-prices.ts`, change merge order when building `baseContext` so `customer` and `region` from `setPricingContextResult` take precedence over cart-derived values when pricing variants.
> - **Changeset**:
> - Add patch changeset for `@medusajs/core-flows`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 010da7340909016692bea183d022dd0585abdb5a. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
## Summary
**What** — What changes are introduced in this PR?
- Add missing `images` field of variants to the HTTP types
- Add missing `thumbnail` field to product variant schema, which leads to the thumbnail missing from auto generated types
**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.
