* Avoid throwing prices not found error when line item is custom unit price
* Add changeset
* Avoid throwing upo variant price validation for custom priced item variants
## Summary
**What** — What changes are introduced in this PR?
Export Zod as a dependency of `@medusajs/framework`.
Closes DX-2414
**Why** — Why are these changes relevant or necessary?
Zod is an essential part of Medusa development. We use it in the core and developers use it in their customizations.
Developers using pnpm won't have access to Zod, as it's not a top-level dependency. While they can install any version, since Zod is an essential aspect of our framework, it's more convenient that we export it and make it accessible to developers.
**How** — How have these changes been implemented?
1. Add Zod as a dependency in `@medusajs/deps` and export it in `@medusajs/framework`
2. Change imports of Zod across projects to import from `@medusajs/framework` and remove the Zod dependency.
> Note: this change doesn't cover admin extensions (and our related packages), as they're not related to the Medusa framework and using Zod in them isn't part of the conventions we document.
Developers can import Zod like this now:
```ts
import { z } from "@medusajs/framework/zod"
```
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Use the following import in a Medusa project to create an validate zod schemas:
```bash
import { MedusaRequest, MedusaResponse } from "@medusajs/framework/http";
import { z } from "@medusajs/framework/zod"
export const PostCustomSchema = z.object({
name: z.string(),
})
type PostCustomSchema = z.infer<typeof PostCustomSchema>
export async function POST(
req: MedusaRequest<PostCustomSchema>,
res: MedusaResponse
) {
res.json({
message: `Hello, ${req.validatedBody.name}`
})
}
// in middleware
import { defineMiddlewares, validateAndTransformBody } from "@medusajs/framework/http"
import { PostCustomSchema } from "./admin/custom/route"
export default defineMiddlewares({
routes: [
{
matcher: "/custom",
middlewares: [validateAndTransformBody(PostCustomSchema)],
},
],
})
```
---
## Examples
-
---
## 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
-
* fix(build): Introduce a schema only flag for more heavy light weight loading
* fix(build): cleanup and tests
* Create shy-snails-raise.md
* fix(build): cleanup
* feat(DML): Add a new translatable property modifier applicable on text
* feat(DML): Add a new translatable property modifier applicable on text
* feat(DML): Add a new translatable property modifier applicable on text
* Create gold-bobcats-decide.md
* feat(DML): Add a new translatable property modifier applicable on text
* feat(DML): Add a new translatable property modifier applicable on text
* simplification
1. Fix error when passing `--version` and installing Next.js storefront. The error is because the UI package doesn't follow the same versioning as other Medusa packages, so this will skip updating the version of the UI package.
2. Other: added error logging for installation errors
* feat(translation): Add support for locale to the graph query
* feat(translation): Add support for locale to the graph query
* feat(translation): Add support for locale to the graph query
* feat(translation): fix import
* fix
* cleanup
* fix context in product routes
* Create dull-onions-punch.md
## Summary
**What** — What changes are introduced in this PR?
Add missing filters like `ean, upc, barcode` and fields like `thumbnail` to product variants endpoints.
**Why** — Why are these changes relevant or necessary?
We had a disconnection between the allowed filters and fields for variants in the products endpoint and in the product variants endpoint.
**How** — How have these changes been implemented?
Avoid this issue in the future by removing redundant definitions for fields and filters for variants in the products and variants endpoints, consolidating them in the variants endpoint and implementing imports in the products endpoint. Add missing fields/filters to product variants endpoint.
**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
Add any additional context, related issues, or references that might help the reviewer understand this PR.
fixes SUP-2872
* Avoid checking existent inventory item on fulfillment cancellation for variants without managed inventory
* Add changeset
* Dismiss existent variant inventory links when updating to unmanaged inventory
* Update input type and step name
* Dismiss inventory when variant is updated to unmanaged inventory
* Review changes
* Fix
* Fix
* Comments
* Include Map to avoid iterating unnecessarily
## Summary
**What**
Adds metadata field for reset password route that allows passing data from caller that can be found in the subscriber.
## 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]
> Introduces optional request `metadata` for reset-password and propagates it through to event subscribers.
>
> - Accepts `metadata` in `ResetPasswordRequest` validator and `reset-password` route; forwards it to `generateResetPasswordTokenWorkflow`
> - Workflow now accepts `metadata` and includes it in emitted `auth.password_reset` event data
> - Updates event docs to mention `metadata` field
> - Adds integration test verifying `metadata` is emitted in the password reset event
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 7f9855feabed284336e8872eebfb18fe3bd320db. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
**What**
- fix an issue where switching between `across` promotion types in the create form wouldn't set `max_quantity` to null which would cause the create request to fail
---
CLOSES https://github.com/medusajs/medusa/issues/14365
---
> [!NOTE]
> Prevents invalid `max_quantity` when switching templates to an *across* allocation in the promotion creation flow.
>
> - In `create-promotion-form.tsx`, after applying template defaults, explicitly sets `application_method.max_quantity` to `null` if `application_method.allocation` is `"across"` to avoid resetting it to `1`
> - Adds a changeset entry for `@medusajs/dashboard` patch release
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 5b08c77fee741ec5de399b4f1f9e245ba69b5bee. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
## Summary
**What** — What changes are introduced in this PR?
Add translations management to draft orders list page.
**Why** — Why are these changes relevant or necessary?
We were using hardcoded English strings.
**How** — How have these changes been implemented?
Remove hardcoded strings and replace them with dynamic translations.
**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
Add any additional context, related issues, or references that might help the reviewer understand this PR.
closes#14377
## Summary
Ensure that address deletion during order deletion is handled correctly with respect to cascading deletes. Currently, when deleting an order that does not have a shipping or billing address, we incorrectly attempt to delete all order addresses. This happens because `undefined` address IDs are not handled properly during deletion.
More specifically, when deleting an order without addresses, the following method is called with these arguments:
```ts
await deleteOrderAddresses([undefined, undefined])
```
This triggers deletion of all order addresses.
To make matters worse, because we have a cascade delete defined from order addresses to orders, the same call also deletes all associated orders.
The root cause is the following filtering logic:
```ts
const orderAddressIds = orders
.map((order) => [order.shipping_address_id, order.billing_address_id])
.flat(1)
```
For orders without addresses, this produces `[undefined, undefined]` as input filter, which our delete methods interpret as:
```ts
await delete({ '$or': [ { id: undefined }, { id: undefined } ] })
```
This effectively translates to “delete all addresses.”
In this PR, we make two changes to prevent this going forward:
1. Filter out undefined address IDs before attempting deletion
2. Remove the cascade delete from address to order, as this is an aggressive constraint
The latter change is open for discussion, but cascading deletes from a child entity to a parent is slightly off IMO. Let me know your thoughts.
## 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
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
---
> [!NOTE]
> Strengthens order deletion to avoid unintended cascades and validates behavior with tests.
>
> - Update FK constraints in migration to `ON DELETE SET NULL` for `order.shipping_address_id` and `order.billing_address_id` (was `CASCADE`)
> - In `order-module-service.ts` `deleteOrders`, filter falsy address IDs and conditionally batch-delete `order_address`/`order_change` via `promiseAll`
> - Add integration tests `integration-tests/__tests__/delete-order.spec.ts` covering deletion of orders and associated entities, deleting orders without addresses (no cross-order impact), and address deletion setting `NULL` on the order
> - Add changeset marking `@medusajs/order` patch
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 8e4ab59af407ec865f73fbf286ec93e710915c8e. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
1. Fix the customer details page crashing when a customer's order is fully refunded. The error was originating from the payment collections of the order not being retrieved, since they're being used to calculate the refunded total.
2. Other: fix country not showing as well due to incorrectly trying to retrieving and access the shipping address's country
Closes#14409
* feat(): Translation settings + user configuration
* feat(): Translation settings + user configuration
* Create gentle-bees-grow.md
* add entities end point
* add entities end point
* add admin hook and js sdk method
* update changeset
* fix tests
* fix tests
* rm unnecessary copy
* update dashboard to use the new resources
* update dashboard to use the new resources
* update dashboard to use the new resources
* allow type inference through interface augmentation in the defineConfig of medusa-config
* allow type inference through interface augmentation in the defineConfig of medusa-config
* exclude id and _id props
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
The translation module's defaults loader throws a warning on every server
restart after the first run because the upsert method uses `id` as the
unique key, but defaultLocales only contains `code` and `name`.
This causes the upsert to always attempt creation, which fails on the
unique `code` constraint with: "Locale with code: en-US, already exists."
Fix: Fetch existing locales first and map their IDs into defaultLocales
so upsert can properly identify existing records and update them.
Fix type argument for requests which is necessary for generating OpenAPI specs
## Why
The `StoreVariantListRequest` type used in the `/store/product-variants` route doesn't match the convention of other routes since it doesn't accept a type parameter for the query (or body, but here that's not necessary). This makes it difficult for us to infer the query parameter type of the request.
This change would adapt the `StoreVariantListRequest` to match other conventions in our API routes so that we can generate correct OAS for docs
