[jira] [Commented] (OFBIZ-13663) Fix regressions in OrderServicesScript.groovy introduced by the mini-lang conversion

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125046#comment-18125046 ] 

ASF subversion and git services commented on OFBIZ-13663:
---------------------------------------------------------

Commit e955a1466e9e9d2fc28dc26f1f502fc3dd907941 in ofbiz-framework's branch refs/heads/trunk from Mridul Pathak
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=e955a1466e ]

Fixed: Regressions in OrderServicesScript.groovy introduced by the mini-lang conversion (OFBIZ-13663)

The Groovy conversion of OrderServices.xml (OFBIZ-9984) changed the behaviour of several services. Restore the mini-lang behaviour:

- createOrderHeader: set the non-PK fields outside the with{} closure, which resolved "parameters" on the GenericValue and threw
- setUnitPriceAsLastPrice: convert the String itemPriceMap values to BigDecimal instead of casting, and compare the order currency price or unit cost as BigDecimals with the original if/else structure
- recreateOrderAdjustments: stop the loop variable from shadowing the orderItemSeqId assigned in the with{} closure, and take the promo item id from the per-order sub-sequence
- checkOrderIsOnBackOrder: use "greater than" for quantityNotAvailable, as the mini-lang did
- getOrderItemShipGroupEstimatedShipDate: look the ship group up by orderId and shipGroupSeqId and null-guard the results
- createUpdateShippingAddress and createUpdateBillingAddress: look up the existing PostalAddress by the address context's contactMechId, and in the "use shipping address for billing" branch expire the old billing purposes and delete the contact mech only when keepAddressBook is N
- createUpdateCreditCard: filter the payment methods by date and keep the supplied paymentMethodId when none is found
- productAvailabilityByFacility: only filter by ownerPartyId when one is given
- createOrderPaymentApplication: order the order item billings by invoiceId


> Fix regressions in OrderServicesScript.groovy introduced by the mini-lang conversion
> ------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-13663
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-13663
>             Project: OFBiz
>          Issue Type: Bug
>          Components: order
>    Affects Versions: Upcoming Branch
>            Reporter: Mridul Pathak
>            Assignee: Mridul Pathak
>            Priority: Major
>
> Re-audit of {{OrderServicesScript.groovy}} against {{OrderServices.xml}} (conversion {{57bf0ce268}}, OFBIZ-9984). All permission checks are preserved.
> *1. {{createOrderHeader}} always throws.* {{orderHeader.with { setNonPKFields(parameters) ... }}} resolves {{parameters}} on the delegate first; the GenericValue rejects the unknown field with an IllegalArgumentException. Use {{orderHeader.setNonPKFields(parameters)}} outside the closure.
> *2. {{setUnitPriceAsLastPrice}} fails on every purchase-order item update.* {{BigDecimal unitPrice = itemPrice.getValue()}} assigns the String values of {{itemPriceMap}} to a BigDecimal and throws {{GroovyCastException}}; the ECA on {{updateOrderItems}} for PURCHASE_ORDER runs it synchronously. Convert the values explicitly.
> *3. {{setUnitPriceAsLastPrice}} compares Strings to BigDecimals* in the facility branch ({{orderCurrencyUnitPrice}} and {{unitCost}} are String attributes), so the values always differ and a new SupplierProduct row is created on every receipt. In the mini-lang the {{else}} also belonged to the {{orderCurrencyUnitPrice}} test only.
> *4. {{recreateOrderAdjustments}} never sets {{OrderItemShipGroupAssoc.orderItemSeqId}}.* Inside {{newOisga.with { orderItemSeqId = newOrderItem.orderItemSeqId }}} the assignment hits the enclosing loop variable of the same name, not the entity, so the create fails with a null key part for promotion items.
> *5. {{recreateOrderAdjustments}} allocates the promo item id from a global sequence* ({{delegator.getNextSeqId('OrderItem')}}) instead of the per-order sub-sequence ({{make-next-seq-id}}); ids such as {{10000}} can later collide within an order.
> *6. {{checkOrderIsOnBackOrder}} uses {{>=}} instead of {{>}}* on {{quantityNotAvailable}}, so fully reserved rows (quantityNotAvailable = 0) count as back-ordered.
> *7. {{getOrderItemShipGroupEstimatedShipDate}} looks up the wrong ship group:* by {{contactMechId = parameters.oldContactMechId}} (not a declared attribute) instead of the primary key {{orderId + shipGroupSeqId}}, and then dereferences {{maySplit}} / {{promisedDatetime}} without null checks.
> *8. {{createUpdateBillingAddress}}, "use shipping address for billing" branch.* The mini-lang expired each BILLING_LOCATION purpose of the old bill-to address ({{expirePartyContactMechPurpose}}) and called {{deletePartyContactMech}} only when {{keepAddressBook == 'N'}}. The Groovy calls {{deletePartyContactMech}} for every purpose row, which removes the old address from the address book even with {{keepAddressBook = 'Y'}} (the default), and for {{'N'}} calls {{createPartyContactMechPurpose}} with only a {{contactMechId}}, which fails validation.
> *9. The "did the address change" lookup finds nothing.* {{createUpdateShippingAddress}} (two places) and {{createUpdateBillingAddress}} use {{from('PostalAddress').where(parameters).queryOne()}}, but {{parameters}} has no {{contactMechId}} ({{shipToContactMechId}} / {{billToContactMechId}} only), so {{oldValue}} is always null and an unchanged address is re-created on every submit. Use the id from the address context.
> *10. {{createUpdateCreditCard}} lost {{filterByDate}}* and substitutes {{''}} when no PaymentMethod is found, so an expired card can be updated, or {{updateCreditCard}} receives an empty id.
> *11. {{productAvailabilityByFacility}}* now filters {{ownerPartyId IS NULL}} when no owner is passed; the mini-lang returned all facilities.
> *12. {{createOrderPaymentApplication}}* lost the {{order-by invoiceId}}, so with several invoices an arbitrary one is picked.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)