## 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
This pull request enhances the entity column generation logic in the admin views by adding support for including fields from additional GraphQL types, specifically for the `orders` entity. The changes allow more flexible and comprehensive column definitions by pulling in fields from related types (like `OrderDetail`) and updating the filtering and type resolution logic accordingly.
**This adding payment_status & fulfillment_status from OrderDetail in view configuration feature**
**Entity column generation enhancements:**
* Added the `ADDITIONAL_ENTITY_TYPES` mapping to specify extra GraphQL types whose fields should be included for certain entities (currently, `OrderDetail` for `orders`). ([packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsR260-R263](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02R260-R263))
* Updated the column generation process to collect fields from both the main entity type and any additional types, while properly filtering out arrays and excluded fields. ([packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsR340-R345](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02R340-R345), [packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsR373-R414](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02R373-R414))
* Changed field lookup logic to use a unified `entityFields` object and a new `additionalFieldDefinitions` map for extra fields, ensuring correct type info resolution for all columns. ([packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsL344-R354](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02L344-R354), [packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsL411-R463](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02L411-R463))
### What
Add a new `once` allocation strategy to promotions that limits application to a maximum number of items across the entire cart, rather than per line item.
### Why
Merchants want to create promotions that apply to a limited number of items across the entire cart. For example:
- "Get $10 off, applied to one item only"
- "20% off up to 2 items in your cart"
Current allocation strategies:
- `each`: Applies to each line item independently (respects `max_quantity` per item)
- `across`: Distributes proportionally across all items
Neither supports limiting total applications across the entire cart.
### How
Add `once` to the `ApplicationMethodAllocation` enum.
Behavior:
- Applies promotion to maximum `max_quantity` items across entire cart
- Always prioritizes lowest-priced eligible items first
- Distributes sequentially across items until quota exhausted
- Requires `max_quantity` field to be set
### Example Usage
**Scenario 1: Fixed discount**
```javascript
{
type: "fixed",
allocation: "once",
value: 10, // $10 off
max_quantity: 2 // Apply to 2 items max across cart
}
Cart:
- Item A: 3 units @ $100/unit
- Item B: 5 units @ $50/unit (lowest price)
Result: $20 discount on Item B (2 units × $10)
```
**Scenario 2: Distribution across items**
```javascript
{
type: "fixed",
allocation: "once",
value: 5,
max_quantity: 4
}
Cart:
- Item A: 2 units @ $50/unit
- Item B: 3 units @ $60/unit
Result:
- Item A: $10 discount (2 units × $5)
- Item B: $10 discount (2 units × $5, remaining quota)
```
**Scenario 3: Percentage discount - single item**
```javascript
{
type: "percentage",
allocation: "once",
value: 20, // 20% off
max_quantity: 3 // Apply to 3 items max
}
Cart:
- Item A: 5 units @ $100/unit
- Item B: 4 units @ $50/unit (lowest price)
Result: $30 discount on Item B (3 units × $50 × 20% = $30)
```
**Scenario 4: Percentage discount - distributed across items**
```javascript
{
type: "percentage",
allocation: "once",
value: 15, // 15% off
max_quantity: 5
}
Cart:
- Item A: 2 units @ $40/unit (lowest price)
- Item B: 4 units @ $80/unit
Result:
- Item A: $12 discount (2 units × $40 × 15% = $12)
- Item B: $36 discount (3 units × $80 × 15% = $36, remaining quota)
Total: $48 discount
```
**Scenario 5: Percentage with max_quantity = 1**
```javascript
{
type: "percentage",
allocation: "once",
value: 25, // 25% off
max_quantity: 1 // Only one item
}
Cart:
- Item A: 3 units @ $60/unit
- Item B: 2 units @ $30/unit (lowest price)
Result: $7.50 discount on Item B (1 unit × $30 × 25%)
```
