fix(core-flows,order): update order.email on accepted customer transfer

[NicolasGorga]

Summary

What — What changes are introduced in this PR?

Update order.email upon customer transfer acceptance.

Why — Why are these changes relevant or necessary?

To prevent the order from retaining a link to the old customer email and align it to it's customer relation after the transfer is accepted.

How — How have these changes been implemented?

When processing the transfer customer action operation set the order.email property.

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.

// 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.

fixes #14161

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

8 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
api-reference	Ignored			Dec 7, 2025 4:50am
api-reference-v2	Ignored			Dec 7, 2025 4:50am
cloud-docs	Ignored			Dec 7, 2025 4:50am
docs-ui	Ignored			Dec 7, 2025 4:50am
docs-v2	Ignored			Dec 7, 2025 4:50am
medusa-docs	Ignored			Dec 7, 2025 4:50am
resources-docs	Ignored			Dec 7, 2025 4:50am
user-guide	Ignored			Dec 7, 2025 4:50am

[changeset-bot]

🦋 Changeset detected

Latest commit: 1aae673

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 74 packages

Name	Type
@medusajs/core-flows	Patch
@medusajs/order	Patch
@medusajs/medusa	Patch
integration-tests-http	Patch
@medusajs/test-utils	Patch
@medusajs/medusa-oas-cli	Patch
@medusajs/analytics	Patch
@medusajs/api-key	Patch
@medusajs/auth	Patch
@medusajs/caching	Patch
@medusajs/cart	Patch
@medusajs/currency	Patch
@medusajs/customer	Patch
@medusajs/file	Patch
@medusajs/fulfillment	Patch
@medusajs/index	Patch
@medusajs/inventory	Patch
@medusajs/link-modules	Patch
@medusajs/locking	Patch
@medusajs/notification	Patch
@medusajs/payment	Patch
@medusajs/pricing	Patch
@medusajs/product	Patch
@medusajs/promotion	Patch
@medusajs/region	Patch
@medusajs/sales-channel	Patch
@medusajs/settings	Patch
@medusajs/stock-location	Patch
@medusajs/store	Patch
@medusajs/tax	Patch
@medusajs/user	Patch
@medusajs/workflow-engine-inmemory	Patch
@medusajs/workflow-engine-redis	Patch
@medusajs/draft-order	Patch
@medusajs/oas-github-ci	Patch
@medusajs/cache-inmemory	Patch
@medusajs/cache-redis	Patch
@medusajs/event-bus-local	Patch
@medusajs/event-bus-redis	Patch
@medusajs/analytics-local	Patch
@medusajs/analytics-posthog	Patch
@medusajs/auth-emailpass	Patch
@medusajs/auth-github	Patch
@medusajs/auth-google	Patch
@medusajs/caching-redis	Patch
@medusajs/file-local	Patch
@medusajs/file-s3	Patch
@medusajs/fulfillment-manual	Patch
@medusajs/locking-postgres	Patch
@medusajs/locking-redis	Patch
@medusajs/notification-local	Patch
@medusajs/notification-sendgrid	Patch
@medusajs/payment-stripe	Patch
@medusajs/framework	Patch
@medusajs/js-sdk	Patch
@medusajs/modules-sdk	Patch
@medusajs/orchestration	Patch
@medusajs/types	Patch
@medusajs/utils	Patch
@medusajs/workflows-sdk	Patch
@medusajs/cli	Patch
@medusajs/deps	Patch
@medusajs/telemetry	Patch
@medusajs/admin-bundler	Patch
@medusajs/admin-sdk	Patch
@medusajs/admin-shared	Patch
@medusajs/admin-vite-plugin	Patch
@medusajs/dashboard	Patch
@medusajs/icons	Patch
@medusajs/toolbox	Patch
@medusajs/ui-preset	Patch
create-medusa-app	Patch
medusa-dev-cli	Patch
@medusajs/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[olivermrbl]

thought: based on the comments in the code, keeping the original email seemed to have been a very intentional action. I can't remember why, but maybe @fPolic can pitch in

[fPolic]

keeping the original email seemed to have been a very intentional action

I think we wanted to keep email associated with the order in case purchase was intentionally made with that email and the email needs to be associated with the purchased good.

This seems to be an issue when doing transfers between registered accounts (while the original idea behind this feature was to allow claiming an order from unregisterd -> registered account).
However, solution could be for users to implement this when sending the request email as described in the issue:

// send confirmation to this email in subscriber
const emailToConfirmTransfer = order.customer?.email ?? order.email

• if customer is an unregistered account, we will have the same behaviour and the email will be sent to order.email
• if customer is registered account, email will be send to the current registered owner

[NicolasGorga]

keeping the original email seemed to have been a very intentional action

I think we wanted to keep email associated with the order in case purchase was intentionally made with that email and the email needs to be associated with the purchased good.

This seems to be an issue when doing transfers between registered accounts (while the original idea behind this feature was to allow claiming an order from unregisterd -> registered account). However, solution could be for users to implement this when sending the request email as described in the issue:

// send confirmation to this email in subscriber
const emailToConfirmTransfer = order.customer?.email ?? order.email

• if customer is an unregistered account, we will have the same behaviour and the email will be sent to order.email
• if customer is registered account, email will be send to the current registered owner

But I think not the majority of the cases would need this: I think we wanted to keep email associated with the order in case purchase was intentionally made with that email and the email needs to be associated with the purchased good. so it would confuse the ones that don't need these. The few cases that need this, would be able to still retrieve the original customer's email through the first order change action type TRANSFER_CUSTOMER no?