feat(core-flows,dashboard,js-sdk, medusa,types,utils): support notification preferences for order edits - #16238
Conversation
…ification when requesting an order edit
🦋 Changeset detectedLatest commit: 881b6c4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 79 packages
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 |
|
Thanks for the contribution! Initial automated review looks good. Team-member PR wiring the order-edit notification preference end-to-end. Adds a nullable boolean column to the order_change table (migration included), validates the new field via Zod in the request route, stores it on the order change, and emits it in both the requested and confirmed events. Dashboard UI toggle is now correctly plumbed. Integration test covers the full flow. JS-SDK breaking change (parameter-order) is correctly marked minor in the changeset. No security, performance, or correctness issues found. Triggered by: manual workflow dispatch |
In the order edit form, we had an input to configure whether to send a notification, but it wasn't actually being set or passed anywhere. We had a
TODOto wire it up.This PR adds support for order edit notification preferences:
no_notificationproperty to theOrderChangedata modelno_notificationin the API route and workflow for requesting order edit.no_notificationon the order change and emit it in the request eventno_notificationin the confirmation workflow and emit it in the confirmation eventBreaking change
This PR has a breaking change on the JS SDK's
sdk.admin.orderEdit.request. It now accepts the body as a request parameter, makingquerythe third, andheaders4th.Closes DX-2829