## Summary
**What** — What changes are introduced in this PR?
Remove `default_locale` from Store <> Locale relation
**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.
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
* feat: order export
* Merge branch 'develop' of https://github.com/medusajs/medusa into feat/order-export
* normalize status
* rm util
* serialize totals
* test
* lock
* comments
* configurable order list
## 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
* 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>
## 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
**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
## 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>
* 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" />
* Add preprocess to version param to validate as number
* Add changeset
* Use the first version of the order as the starting node of activity to show correct total
* Add changeset
* Fetch first order version only if it's not the current version
* Remove conditionally rendered hook, use enable config
## Summary
**What** — What changes are introduced in this PR?
Include `material` field in the product detail summary UI section, to match the structure of the same edit UI, which includes the field.
**Why** — Why are these changes relevant or necessary?
Without this there is no UI to see the current value of the `material` field/
**How** — How have these changes been implemented?
Added a section row including the `material` field in the product detail summary section.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Verified the field shos up as expected in the admin dashboard.
---
## 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#14019
closes SUP-2686
* feat(dashboard): Update error message for large files
Update error message for uploads of files that exceed their limit
Related https://github.com/medusajs/medusa/pull/13981
* Added changeset
## Summary
**What** — What changes are introduced in this PR?
Limit file uploads to 1MB
**Why** — Why are these changes relevant or necessary?
Prevent large file uploads in the Admin
**How** — How have these changes been implemented?
Set size limits on the file uploads
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
---
## 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
CLOSES CORE-1270
---
> [!NOTE]
> Adds a 1MB default file size limit to `FileUpload`, surfaces size/type rejections in media forms via new i18n, and allows unlimited size for product import.
>
> - **Components**:
> - `components/common/file-upload/file-upload.tsx`:
> - Add `maxFileSize` (default 1MB) and size validation; return `rejectedFiles` alongside valid files.
> - **Products › Media Upload**:
> - `upload-media-form-item.tsx`:
> - Handle `rejectedFiles` and set form errors for invalid type and oversized files.
> - **Products › Import**:
> - `upload-import.tsx`: Use `maxFileSize={Infinity}` to disable size limit for CSV import.
> - **i18n**:
> - Schema and EN translations: add `products.media.fileTooLarge` message.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit c8c67f4d329f8767e99694649bf0b3fe4cf400e9. 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?
*Adds a new pt-PT translation file for the Medusa Admin Dashboard and registers the Portuguese (Portugal) locale in the i18n configuration.*
**Why** — Why are these changes relevant or necessary?
*To provide full localization support for users in Portugal. The Admin currently includes a pt-BR translation, and this PR adds proper European Portuguese equivalents with consistent terminology and grammar.*
**How** — How have these changes been implemented?
*Created a new file ptPT.json following the same structure as en.json and ptBR.json.*
*Registered the "pt-PT" locale in the i18n resources and language selector.*
*Verified placeholder consistency ({{ }}, <0></0>, etc.) and kept all keys identical to the English source.*
**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
- [ 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.
---
> [!NOTE]
> Adds European Portuguese (`ptPT`) translations and registers the locale in i18n resources and the language selector.
>
> - **i18n**:
> - Add `ptPT` translation file `packages/admin/dashboard/src/i18n/translations/ptPT.json`.
> - Register `ptPT` in `packages/admin/dashboard/src/i18n/translations/index.ts` resources.
> - Register `ptPT` in `packages/admin/dashboard/src/i18n/languages.ts` with `date-fns` locale and display name "Português (Portugal)".
> - **Changeset**:
> - Add patch changeset for `@medusajs/dashboard`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4cf30255609fa33d0c0362858c35e094b97d68e1. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Co-authored-by: William Bouchard <46496014+willbouch@users.noreply.github.com>
## Summary
**What** — What changes are introduced in this PR?
Fix to prevent InfiniteList component from falling into an infinite loop of requests.
Before:
Uploading Grabación de pantalla 2025-11-03 a la(s) 11.34.55 p. m..mov…
**Why** — Why are these changes relevant or necessary?
The current dependency array of the useEffect in charge of issuing the next/previous fetch calls for pagination, include the functions from `useInfiniteQuery` in its dependency array as well as its body. This causes the component to render infinitely, as the functions reference change on every render.
**How** — How have these changes been implemented?
- Updated the problematic dependency array to not include these functions.
- Included a useEffect and refs for both functions to always have the latest value.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Tested locally that the bug that was happening before the fix was mitigated and i was able to paginate correctly.
After fix:
https://github.com/user-attachments/assets/17d41bf9-6b3f-437b-b2ce-10e4dcbe248a
---
## 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 SUP-2620
---
> [!NOTE]
> Prevents InfiniteList from entering an infinite fetch loop by storing pagination functions in refs and removing them from the effect dependency array.
>
> - **Dashboard**:
> - **`packages/admin/dashboard/src/components/common/infinite-list/infinite-list.tsx`**:
> - Store pagination callbacks in refs: `fetchNextPageRef`, `fetchPreviousPageRef`, synced via `useEffect`.
> - Update `IntersectionObserver` callbacks to call `ref.current()` instead of the functions directly.
> - Remove `fetchNextPage`/`fetchPreviousPage` from the `useEffect` dependency array to stabilize observer setup.
> - **Changeset**:
> - Patch release for `@medusajs/dashboard` describing the fix.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit e21d9998ac01ae048fa7e72713a2027d3fc8cfb6. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* Create lucky-poets-scream.md
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* dedupe snapshot this build
* split into 4 shard
* re configure packages integration tests
* re configure packages integration tests
* re configure packages integration tests
* re configure packages integration tests
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* reduce shard for packages
## Summary
**What** — What changes are introduced in this PR?
- show thumbnail on the product variant list
- refactor variant image editor state management
- await revalidation before rendering form
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Manual testing
---
## 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
## Summary
**What**
Exports the type of medusa's i18n keys from the dashboard package, for autocomplete support.
**Why**
Currently i18next is not able to provide proper ts autocomplete support when adding translations to projects or plugins.
For example when adding a data table or form, I have to go back multiple times to the source i18n files in the medusa repo and search for the exact key name(is it "actions.confirm" or "general.confirm"? etc) and I forget it right after every single time.
Even if all medusa components were provided already translated, it's still very convinient to use keys from medusa(if context appropriate) for some custom components, since they are already translated into many languages(eg "yes", "no" and other very basic strings). Hence why ts support for the base keys would be very helpful
**How**
Modified the generateTypes script to also copy the `en.json` file to the dist folder, and export a `Resources` type with the inferred keys in index.d.ts.
This allows users to define their own i18next type definitions including the base "translation" namespace, example below.
**Testing**
Manual testing
---
## Examples
```ts
// In src/admin/i18next.d.ts
import type enTranslation from "./i18n/en.json" // custom keys
import type { Resources } from "@medusajs/dashboard" // medusa keys
declare module "i18next" {
interface CustomTypeOptions {
fallbackNS: "translation"
resources: {
translation: Resources["translation"]
// all custom namespaces need to merge Resources["translation"] as well
// otherwise when falling back to "translation", strings will have type "never"
myCustomNs: typeof enTranslation & Resources["translation"]
}
}
}
```
Then, both `useTranslation()` and `useTranslation("myCustomNs")` will have proper autocomplete support
---
## 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
## Summary
**What** — What changes are introduced in this PR?
This PR standardizes heading levels across dashboard components to maintain proper semantic HTML hierarchy.
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
- Added optional `headingLevel` prop `"h1" | "h2" | "h3"` to `DataTable` component with default value of `"h1"`
- Modified `Heading` component usage to explicitly specify the appropriate level based on context
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## 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
* Limit the number of ids passed to the different queries to render the tooltip details to 10, for products, product types and shipping options
* Add changeset
* Extract common additional field computation into variable
* virtual i18n module
* changeset
* fallback ns
fallback to the default "translation" ns if the key isnt found. Allows to use a single "useTranslation("customNs")" hook for both custom and medusa-provided keys
* simplify merges
* optional for backward compat
* fix HMR
* fix generated deepMerge
* test
* feat(): version order credit lines
* undo last change
* adjust where
* remove date on ui
* Create five-donuts-obey.md
* add test
* nit comment
* woops
