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>
## Summary
**What** — What changes are introduced in this PR?
Improve Admin UI product detail performance after updating the entity.
**Why** — Why are these changes relevant or necessary?
Products with a lot of relations would cause issues when trying to be updated through various edit components, since the core update api route returns these entities by default.
**How** — How have these changes been implemented?
We remove these unnecessary relations when calling the update route, by passing the `fields` query param with the negation sign for each of these. For example: `fields=-type,-collection...`
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Tested all of the update components and validated they still work correctly, plus, none depend on the returned product to perform an action or render information.
---
## 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
Add any additional context, related issues, or references that might help the reviewer understand this PR.
fixes#13783, #14183
closes CORE-1296, SUP-2791
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
Summary
This PR adds BullMQ queue and worker configuration options to the workflow-engine-redis module, bringing feature parity with the event-bus-redis module. It also introduces per-queue
configuration options for fine-grained control over the three internal queues (main, job, and cleaner).
Key changes:
- Added per-queue BullMQ configuration options (mainQueueOptions, jobQueueOptions, cleanerQueueOptions and their worker counterparts) with shared defaults
- Unified Redis option naming across modules: deprecated url → redisUrl, options → redisOptions (with backward compatibility)
- Moved configuration resolution to the loader and registered options in the DI container
- Added comprehensive JSDoc documentation for all configuration options
- Added unit tests for option merging and queue/worker configuration
Configuration Example
```ts
// Simple configuration - same options for all queues
{
redisUrl: "redis://localhost:6379",
queueOptions: { defaultJobOptions: { removeOnComplete: 1000 } },
workerOptions: { concurrency: 10 }
}
```
```ts
// Advanced configuration - per-queue overrides
{
redisUrl: "redis://localhost:6379",
workerOptions: { concurrency: 10 }, // shared default
jobWorkerOptions: { concurrency: 5 }, // override for scheduled workflows
cleanerWorkerOptions: { concurrency: 1 } // override for cleanup (low priority)
}
```
## Summary
**What** — What changes are introduced in this PR?
Show correct color indicator for payment and fulfillment status columns when `view_configuration` feature flag is enabled on order data table.
**Why** — Why are these changes relevant or necessary?
For non canceled status, grey default indicator was shown, as these columns weren't handled with their dedicated helper functions.
**How** — How have these changes been implemented?
Updated `StatusRenderer` to resolve the label and color for these columns with their helper functions, just like we do for the normal order table.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Validated Admin UI shows correct color indicators when `view_configuration` is enabled.
---
## 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
Add any additional context, related issues, or references that might help the reviewer understand this PR.
closes CORE-1309
* chore(): Run some commands in server mode only
* Create orange-timers-lay.md
* chore(): Run some commands in server mode only
* chore(): Run some commands in server mode only
* chore(): Run some commands in server mode only
## Summary
**What** — What changes are introduced in this PR?
Improve fully refunded order details in the order list of Admin UI.
**Why** — Why are these changes relevant or necessary?
Fully refunded orders did not show a value for the `total` column and its `payment_status` color badge expressed a happy path.
**How** — How have these changes been implemented?
Added the refund amount with line through style for fully refunded orders in the `total` column of order list table and changed the `payment_status` badge color to red
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Validated UI looks as expected
---
## 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
Add any additional context, related issues, or references that might help the reviewer understand this PR.
---
> [!NOTE]
> Show refunded amounts with muted strikethrough in the total column for fully refunded orders and set the refunded payment badge to red, fetching `payment_collections` as needed.
>
> - **Admin Dashboard — Order List**:
> - **Total column**: For `payment_status === "refunded"`, display the sum of `payment_collections.refunded_amount` with `text-ui-fg-muted` and `line-through` via `TotalCell` `className`.
> - **Payment status**: Change `refunded` badge color to red.
> - **Component**: `TotalCell` now accepts optional `className`.
> - **Data**:
> - Add `*payment_collections` to `DEFAULT_RELATIONS` for orders.
> - **Changeset**:
> - Patch release for `@medusajs/dashboard`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 802d24330bceaeba74e11d85886593809876cd8d. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
> [!NOTE]
> Adds a configurable concurrency for link migrations (CLI/commands), forces concurrency=1 when pgstream is detected, and ignores duplicate link-table inserts.
>
> - **CLI**
> - Add `--concurrency` option to `db:migrate` and `db:sync-links`.
> - **Medusa commands**
> - `migrate` and `sync-links` accept `concurrency`; set `DB_MIGRATION_CONCURRENCY` and force `1` when `pgstream` schema exists via new `isPgstreamEnabled`.
> - **Link Modules (migrations)**
> - Execute plan actions with `executeWithConcurrency` using `DB_MIGRATION_CONCURRENCY`.
> - Make link-table tracking inserts idempotent with `ON CONFLICT DO NOTHING` (including bulk/upsert and per-create).
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 07432293c8fe8de30b07920fa47823b9081edacc. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* 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
## Summary
**What** — What changes are introduced in this PR?
Display a tootlipt on line items when creating OrderEdit/Exchange to show which promotions are applied on the items.
---
## 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
- [ ] I have linked the related issue(s) if applicable
<img width="786" height="910" alt="Screenshot 2025-11-25 at 14 11 22" src="https://github.com/user-attachments/assets/644bea00-b8ab-4a70-9a43-7c912ac21208" />
<img width="775" height="792" alt="Screenshot 2025-11-25 at 14 23 26" src="https://github.com/user-attachments/assets/ed935dad-9c2b-4ebd-8b9f-00d929add1ff" />
FIXES https://github.com/medusajs/medusa/issues/13976
**What**
Before applying the sales channel link filter, check if there is a single sales channel or many, if will add a bit of overhead but marginal compare to the improvement for big catalog with single sales channel
---
> [!NOTE]
> Optimizes store products listing by conditionally skipping sales channel link filtering when the index can be used or only one sales channel exists.
>
> - **Store API – `products`** (`packages/medusa/src/api/store/products/middlewares.ts`):
> - Adds `applyMaybeLinkFilterIfNecessary` middleware:
> - Skips link filtering when `IndexEngine` is enabled and no tag/category filters are present.
> - Queries `sales_channels` count; if only one exists, removes `sales_channel_id` filter and proceeds.
> - Integrates this middleware into `GET /store/products` before default filters; `GET /store/products/:id` remains unchanged with `maybeApplyLinkFilter`.
> - **Release**:
> - Adds patch changeset for `@medusajs/medusa`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 8a0b024ea1bc9696f350f34fa77df321e5ecf553. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* Lock markFulfillmentAsDeliveredWorkflow with fulifllment id
* Lock markOrderFulfillmentAsDeliveredWorkflow by orderId before calling markFulfillmentAsDeliveredWorkflow
* Add changeset
