## 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>
* tests for components (WIP)
* finished adding tests to components
* added tests for providers
* add test command to doc tests
* fix imports
* exclude test files
* remove import
* add vitest as dev dependency
* fix build error
* ignore test files from eslint
* fix test from docs-ui
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
