Description Deployment of IOM 4.2.0 fails with an exception javax.ejb.EJBTransactionRolledbackException: Aborting deployment: Found not persisted enum value class bakery.persistence.dataobject.article.classification.ClassificationSystemDefDO with id 20 null Bug null Fixed and verified Closed null Blocker

Description The table allows duplicate entries ("returnReasonDefRef", "supplierRef"). Repro Steps Actual Behavior This is not an issue for current projects where the configuration scripts empty/refill the table at each run. only the configuration of the BluePrint project is not idempotent and shoud be

Description Repro Steps Set up a product stock import configuration that has the canDatapackBeEmpty set to true. Import a BC stock file that has only a header line and nothing else Wait for the import to fail. Actual Behavior The standard import process configuration has a flag that can be set to determine

Description If an order approval is rejected in OMT and the subsequent processing fails for any reason, CheckOrderApprovalRequired might ignore the negative approval and continue processing the orders as if were approved. Repro Steps Seems to be impossible to reproduce - apparently this would require

Description The enum java name is now persisted as column "transmissionTypeName" in the db table TransmissionTypeDefDO. Custom implementation of TransmissionTypeDefDOEnumInterface must be modified accordingly: @Override @Transient @Column ( name = "`transmissionTypeName`") /** * @return name of the transmission type

Description The method ShopDO.getEventRegistryEntryList() will modify the shops field eventRegistryEntryList in a non-thread-safe way. This leads to ConcurrentModificationExceptions. Repro Steps You will need a shop structure that has child and parent shop(s). Setup an event configuration such as email

Description Copied from Repro Steps when changed from Escalation to Bug When trying to map an order to latest version com.theberlinbakery.types.v1_2.StoreOrder during order transmission, I get a parse exception, because the offered JNDI-path points to a bean that returns version 1.0. As the bean that

Actual Behavior Issue 1: Stacktraces from exceptions in the SalesPriceCalculator are suppressed Issue 2: Updates on CustomerDO in CloseInvoicing may fail with an OptimisticLockingException due to parallel updates Expected Behavior stacktrace is logged parallel updates are prevented (pessimistic locking)

Description We have a lot of failures of CloseInvoicingPCBean (I'll attach a log entry). Likely the same invoices are failing over and over, because on a test system there are not much new entries. (I have to guess here because the log does not contain the ID). If I analyze the log correctly, the error

Description Until now, database tables are extended at startup when a new java enum value is detected. (in enums annotated with @PersistedEnumerationTable) This is too late as migration or project sql scripts may refer to such new values and hence fail or even silently skip some tasks, when those enum