Rescales PROMOTION-type Adjustments on rows that were partially
cancelled by a pre-#5127 , which reduced
without rescaling . Reading those rows with the fixed
getters (which divide a adjustment by the ,
instead of ) would otherwise inflate their discount.
order_linecancelOrderByOrderLines()quantityadjustmentsOrderLinePROMOTIONquantityorderPlacedQuantityOrderModifier.modifyOrder() ends in applyPriceAdjustments(), which recomputes the
PROMOTION amounts for every line in the order, including lines not referenced by the
OrderModification. For a subsequently-cancelled line, the stored basis is its current
quantity plus the quantities in order-cancellation history after the order's latest
OrderModification.
Some databases can store a modification and cancellation with the same timestamp. Their
order is then unknowable from persisted data, so the helper throws before writing anything.
Inspect those lines and pass ambiguousOrderLineQuantityBases: use the current quantity if
the modification happened last, or the quantity before cancellation if cancellation happened
last.
Call this from your migration's up() method - it needs no schema change, so it
can run at any point in the migration.
Run it in the same deployment as the upgrade to v3.8, before the server handles any
order cancellation, and never add it in a later migration. From v3.8 a partial
cancellation rescales the line's PROMOTION adjustments itself. The helper cannot tell
those lines apart from lines cancelled before v3.8, so it would scale them a second time
and shrink their discount.
Parameters
QueryRunnerRescaleOrderLinePromotionAdjustmentsOptionsArchitecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.