## Summary
**What** —
Add a providerData field to notifications
**Why** —
We need the ability to pass dynamic fields to specific providers. E.g. CC and BCC for emails
**How** —
Just adding the field to the model
**Testing** —
Added the field to existing tests
## 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]
> Adds `provider_data` to notifications (types, workflow input, DB model/migration) and forwards it in the Medusa Cloud Email provider, with tests updated accordingly.
>
> - **Data/Schema**:
> - Add `provider_data` (`jsonb`) to `notification` model and DB via migration `Migration20251121150408` and snapshot update.
> - **Types/DTOs**:
> - Add optional `provider_data` to `CreateNotificationDTO`, `NotificationDTO`, and `ProviderSendNotificationDTO`.
> - **Workflows**:
> - Extend `send-notifications` step input with `provider_data`.
> - **Providers**:
> - Medusa Cloud Email: include `provider_data` in outgoing request payload.
> - **Tests**:
> - Update integration tests to pass and assert `provider_data` propagation.
> - **Changeset**:
> - Patch bumps for `@medusajs/notification`, `@medusajs/core-flows`, `@medusajs/types`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 6f114c75c974a145ef60213637d7c41bc605a0bf. 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?
This pull request adds support for OXXO payments to the Stripe payment provider module. The main changes include the addition of a new `OxxoProviderService`, updates to type definitions to support OXXO-specific options, and integration of the new service into the provider's exports and registration.
**Why** — Why are these changes relevant or necessary?
I was testing the MedusaJs server, I live in México and here oxxo as a Payment method is very used.
**How** — How have these changes been implemented?
* Introduced `OxxoProviderService` in `stripe-oxxo.ts`, which extends `StripeBase` and configures Stripe payment intents for OXXO, including expiration settings.
* Updated `StripeOptions` and `PaymentIntentOptions` types to include `oxxoExpiresDays` and OXXO-specific payment method options for intent configuration.
* Added `OXXO` to the `PaymentProviderKeys` enum for provider identification.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
You need to launch the medusa server, add Stripe OXXO as Payment Provider in your Store Region (OXXO only works in México and with mxn currency) and set payment_method_data type to oxxo.
Also you need to allow oxxo payment as payment method in stripe and configure your stripe webhook to your medusa server
---
## 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 using nextjs starter
const confirmParams: any = {
return_url: returnUrl,
}
if (isOxxo(providerId)) {
confirmParams.payment_method_data = {
type: "oxxo",
billing_details: {
name:
cart.billing_address?.first_name +
" " +
cart.billing_address?.last_name,
address: {
city: cart.billing_address?.city ?? undefined,
country: cart.billing_address?.country_code ?? undefined,
line1: cart.billing_address?.address_1 ?? undefined,
line2: cart.billing_address?.address_2 ?? undefined,
postal_code: cart.billing_address?.postal_code ?? undefined,
state: cart.billing_address?.province ?? undefined,
},
email: cart.email,
phone: cart.billing_address?.phone ?? undefined,
},
}
await stripe
.confirmPayment({
clientSecret,
confirmParams,
redirect: "if_required",
})
.then(({ error, paymentIntent }) => {
console.log({ error, paymentIntent })
const validateIntent = async (paymentIntent: any) => {
const link =
paymentIntent.next_action?.oxxo_display_details
?.hosted_voucher_url
if (link) {
setSubmitting(false)
setMessage(
"Se ha generado un cupón de pago de OXXO. Por favor, revisa la nueva pestaña abierta."
)
await onPaymentCompleted() // Here I call the function because I have custom logic for creating a pending order
}
}
if (error) {
const pi = error.payment_intent
if (
(pi && pi.status === "requires_capture") ||
(pi && pi.status === "succeeded")
) {
onPaymentCompleted()
}
if (pi && pi.status === "requires_action") {
validateIntent(pi)
return
}
setErrorMessage(error.message || null)
setSubmitting(false)
return
}
if (
(paymentIntent && paymentIntent.status === "requires_capture") ||
(paymentIntent && paymentIntent.status === "succeeded")
) {
return onPaymentCompleted()
}
if (paymentIntent && paymentIntent.status === "requires_action") {
validateIntent(paymentIntent) // This is the action that you normally get
}
})
}
}
// Configuration on the server (medusa-config.ts)
modules: [
{
resolve: "@medusajs/medusa/payment",
options: {
providers: [
{
resolve: "@medusa/payment-stripe",
id: "stripe",
options: {
apiKey: process.env.STRIPE_API_KEY,
webhookSecret: process.env.STRIPE_WEBHOOK_SECRET,
capture: true,
oxxoExpiresDays: 7, // default to 3
},
},
],
},
},
],
// And not necessary buy you can extend even more creating a pending-orders module (for showing the vouchers created that costumer need to pay in the frontend, because if not the order only creates after the user have payed the voucher, for testing is 3 minutes), this is an example model:
import { model } from "@medusajs/framework/utils";
export const PendingOrder = model.define("pending_order", {
id: model.id().primaryKey(),
cart_id: model.text().unique(),
user_id: model.text(),
total: model.number(),
payment_type: model.text(),
voucher_url: model.text().nullable(),
payment_session_id: model.text(), // this are the ones that works to identify the payment
payment_collection_id: model.text(), // this are the ones that works to identify the payment
});
export default PendingOrder;
```
---
## 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
#13804
---
> [!NOTE]
> Adds OXXO payment support to the Stripe provider with configurable expiration days and updates intent option handling and typings.
>
> - **Payment Providers**:
> - **New `OxxoProviderService`** (`services/stripe-oxxo.ts`): configures `payment_intent` for OXXO with `expires_after_days` (defaults to `3`, configurable via `options.oxxoExpiresDays`).
> - Registered in `src/index.ts` and exported from `services/index.ts`.
> - **Types**:
> - `StripeOptions` adds `oxxoExpiresDays`.
> - `PaymentIntentOptions` adds `payment_method_options.oxxo.expires_after_days`.
> - `PaymentProviderKeys` adds `OXXO`.
> - **Core**:
> - `core/stripe-base.ts`: `normalizePaymentIntentParameters` now falls back to `this.paymentIntentOptions.payment_method_options` when not provided in `extra`.
> - **Changeset**:
> - Patch release for `@medusajs/payment-stripe`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4d7fe0658b91e6948f011a73d77a6281c85cdd26. 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
Updated context passed for each variant when calculating prices so that `region` and `customer` coming from `setPricingContext` are not overriden if provided.
*Please provide answer here*
Otherwise you can't provide your own `region` and `customer` objects with additional information and you are left with the ones we pass as part of the cart object to the workflows that execute the hook.
*Please provide answer here*
Changed the order in which we define the default `region` and `cart` fields, taking their value from the cart, to before the destructured `setPricingContextResult`.
*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:
- [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
fixes#13990
closes SUP-2647
---
> [!NOTE]
> Adjust pricing context merge order so `setPricingContext`-provided `customer` and `region` are not overridden when calculating variant prices.
>
> - **Core Flows (pricing)**:
> - In `packages/core/core-flows/src/cart/workflows/get-variants-and-items-with-prices.ts`, change merge order when building `baseContext` so `customer` and `region` from `setPricingContextResult` take precedence over cart-derived values when pricing variants.
> - **Changeset**:
> - Add patch changeset for `@medusajs/core-flows`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 010da7340909016692bea183d022dd0585abdb5a. 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?
Copying the phone number would previously copy the email. Implements a fix to instead copy the expected phone number.
**Why** — Why are these changes relevant or necessary?
Implement the expected functionality
**How** — How have these changes been implemented?
Update the content of the `<Copy ... />` component.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Manual testing was performed
---
## 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-1282
* 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?
- Add missing `images` field of variants to the HTTP types
- Add missing `thumbnail` field to product variant schema, which leads to the thumbnail missing from auto generated types
**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.
## 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
## Summary
**What** — What changes are introduced in this PR?
Use correct HTTP type parameter for the get claim API route
**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.
## Summary
**What** — What changes are introduced in this PR?
Allow users to delete other users and prevent them from deleting themselves.
**Why** — Why are these changes relevant or necessary?
Inability to delete other users causes old users that maybe don't work anymore with the business to have access still.
**How** — How have these changes been implemented?
Inverted the check in the admin delete user endpoint, to allow users deleting other users but themselves.
**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
Add any additional context, related issues, or references that might help the reviewer understand this PR.
closes OPS-97
---
> [!NOTE]
> Enables deleting other users via admin DELETE endpoint while blocking self-deletion, with corresponding integration tests and changeset.
>
> - **Backend**
> - Update `DELETE /admin/users/:id` in `packages/medusa/src/api/admin/users/[id]/route.ts`:
> - Disallow self-deletion when `actor_id === id` with `NOT_ALLOWED` error.
> - Execute `removeUserAccountWorkflow` and return standard delete response.
> - **Tests**
> - Expand `integration-tests/http/__tests__/user/admin/user.spec.ts`:
> - Create a second admin user; delete it and verify auth identity `app_metadata` no longer includes `user_id`.
> - Confirm token still authenticates but access is revoked (401 on `/admin/users/me`).
> - Assert self-deletion returns 400 with message `"A user cannot delete itself"`.
> - **Changeset**
> - Add `.changeset/dull-plants-create.md` (patch for `@medusajs/medusa`).
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit f1f8252b91593b8a8fb03dc9d26460d09a10cfaa. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* 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
