Description Actual behavior When you're having a lot of backoffice users registered in IOM, creating new suppliers via SQL configuration becomes extremely slow. The runtime seems to increase exponentially. Expected behavior Lower performance impact - linear increase in runtime Business impact Increased

Actual Behavior REST-calls from OMT using ShopDO.name instead of ShopDO.shopName as expected by API. If different, the OMT notifies an error. Expected Behavior REST-calls from OMT are working with with correct parameters. null Bug null Verified Closed null Major AdoWorkItem 72857 Products Products 0

Description The total (net) and total (gross) values in the OMT order details are showing the wrong values. They are pulling the subtotal values instead of the totals and do not include any charges. The total tax value seems to be correct. Steps to Repeat Create an order with any kind of charge. Open

Repro Steps Actual Behavior We always have problems to find the root cause of InvalidStateTransitionExceptions because the appropriate StatesControllerBeans only print out the class name, but not the id of the object to get a new state. It is impossible for us to determine the failing object. So it would

Steps to Repeat create an invalid return (e.g. unknown position number / sku) browse to returns tab see exception Actual Behavior If invalid returns have been created (e.g. via REST API), browsing to the returns list might fail. This is caused by an exception in the sales price calculation (e.g. missing

Description When trying to create an order for a new customer, IOM will not import the order if any of the first name fields are missing. Creation of unknown customer is configured. Expected behavior: Order is created without first name being populated as the yaml definition marks it as an optional field

Description When searching for Orders with cancellations or returns, the sql include search for OrderPosDOs with "quantityCanceled" and/or "quantityReturned" greater than 0. Without (partial) index on these fields, this can lead to full table scans. null Bug null Verified Closed null Major AdoWorkItem

Description When ShopDO.shopUsesOMT has been removed the according business logic has been deleted. This lead to a breaking change in order response validation for situations where this was previously set to "false", without any chance to mitigate this other than replacing the whole class. See #50416

Description [No Description]Actual Behavior The PaymentNotificationLogicBean missing the discountedAmount for the salesSum's mapping. Expected Behavior salesSum mapping also include the discountedAmounts. Impact E.g. when creating a refund the value for a position can't be correctly refunded due to missing

Repro Steps 1) can be reproduced by adding a custom job with a long runtime (Thread.sleep) 2) can be reproduced by stopping the database or terminating the connections Actual Behavior 1) When a scheduled job runs longer than the time configured at "expectedRuntime", JobHandlerBean will log warnings and

Description When trying to import "fixed" product data after importing "wrong" product data, these updates may lead to completely inconsistent product data when said products are delivered by multiple suppliers. Repro Steps Products: First batch PROPER_PRODUCT_SUPPLIER_A: manufacturerArticleNo = 'MAN_A'

Description When a job takes a lot of time, bakery.control.job.Timer is stuck in a blocking call awaiting the job to finish. Due to the singleton pattern / EJB scheduler the Timer is not fired anymore which basically prevents all other jobs from firing until the blocking call has finished. Repro Steps

Description There are multiple performance issues when handling large orders (e.g. 700-1000 items). So far these issues have been identified in a testorder with > 700 items: Order creation (REST) is slow -> 30s opening order details page in OMT --> 120s-180s Order history (REST) -> 30s RMA (REST) ->

Description [No Description]Actual Behavior After switching from self-hosted to a managed postgres instance in Azure, import performance dropped significantly for *small* files. Example: on a local environment it takes about 300ms to import an inventory file with 2 products, on a managed instance small

Description Order withh 1000 positions cannot be dispathed from the OMT : org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.RuntimeException: io.undertow.util.ParameterLimitException: UT000047: The number of parameters exceeded the maximum of

Repro Steps run test "IOM-64568-024: add a second charge to a bucket, then remove it and send a charge with the same id for the order sale" for the charges and "IOM-64568-019: successfully add, move position between shippingBuckets" for order positions Actual Behavior The order change process tries to

Description The issue has been found while analzing severe performance issues on a production system. Those indexes have been addded: CREATE INDEX IF NOT EXISTS "index_OrderPosTaxDO_orderPosRef" on oms."OrderPosTaxDO"("orderPosRef"); CREATE INDEX IF NOT EXISTS "index_OrderChargeTaxDO_orderChargeRef"

Repro Steps Run test "64568-116: successfully add, move position between shippingBuckets" in OCRValidChangesSpec.groovy Actual Behavior When trying to move a position from one bucket to another with the setPositions() method, the position doesn't move. Expected Behavior The position should be able to

Repro Steps Run test "64568-115: successfully add, remove, modify position of shippingBucket" in OCRValidChangesSpec.groovy Actual Behavior When setting new positions for a shipping bucket the 'old' positions are still there Expected Behavior When setting new positions for a shopping bucket they should

Repro Steps Run test "64568-107: successfully add, modify, remove shipping bucket charge" in OCRValidChangesSpec.groovy Actual Behavior When setting two new charges for the shipping bucket, after already setting one charge, only the original charge remains. Expected Behavior Setting new charges removes