You are viewing the documentation for Blueriq 16. Documentation for other versions is available in our documentation directory.
Identifier | Component | Issue | Solution |
---|---|---|---|
BQ-22351 | A CVE was detected on the spring framework library for version lower than 6.1.3, 6.0.16 and 5.3.31. See [CVE-2024-22243: Spring Framework URL Parsing with Host Validation | We've updated our latest components to spring-boot 3.1.9, which contains spring framework 6.0.17. Older components are updated to spring framework 5.3.32 | |
BQ-22258 | When a lock is created in the database (manually) and you try to remove this, an error occurs | Operations on the maintenance API that change data also update the DCM lists. To do this, the outbox is used which requires an existing transaction. In this case the operation to remove a lock was not transactional, leading to an error with the outbox. The method is now made transactional to fix this. | |
BQ-22256 | Material | Nested external flows are started on the incorrect runtime when no base url is configured in the connection properties. | Nested external flows are now started on the correct runtime. |
BQ-22247 | Material | External flows that do not have a base url configured in the connection properties are not closed, resulting in unnecessary leftover sessions | External flow sessions are now correctly closed even when there is not base url configured. |
CSD-5124 | JAVA Runtime | Project initialization could be slow with many flows | In addition to the improvements that were released in the previous patch, further optimizations have been identified and applied |
CSD-5094 | JAVA Runtime | The Esapi dependency that was packaged with Blueriq was not jakarta namespace compatible. | We moved to the recently release jakarta namespace compatible version of the Esapi dependency. |
BQ-22108 | In some circumstances, it is possible that a startTask lock is left in the database. This is a problem as it prevents that task from being started again. | As startTask locks only exist to prevent automatic tasks from being started twice, it is ensured that they are always deleted directly after that check. | |
CSD-5081 | There are two issues here. When switching pages in the case locks tab, the requests to the backend in the maintenance app are not created properly, which causes duplication in the requests. This did not influence the behavior. The other issue was that case locks occurred on different pages. This only happens when the column that was used to sort the locks would contain duplicates. (then the sorting would show unexpected behavior). | The first issue is solved by removing the duplication from requests when switching pages. The second issue was solved by adding a second sorting option to always sort on the unique identifier such that the default sorting can fallback when the default sorting row contains duplicates. Other pages in the maintenance app contained the same issues and are also solved. | |
CSD-5048 | When the case engine completes a task and fails during that transaction everything except the case locks action will be rolled back as they are outside this transaction. | Added a custom rollback mechanism that rollbacks the release of case locks at the end of the transaction should it fail. | |
CSD-4835 | Encore | In datamappings, the distinction between the first source collection and the additional source collections was not clear. | Changed the appearance of the source collections so that it is now clear that the additional source collections are different from the main source collection, and updated the documentation to clarify the difference. |
BQ-19477 | JAVA Runtime | When using external flows with an in-memory store, it was impossible to set the session timeout, even when following the instructions in the related warning in the log. | It is now possible to set the session timeout for external flows when using an in-memory store, by using the server.servlet.session.timeout property. |
BQ-19471 | JAVA Runtime | When using the external flow with an in-memory store, stored data could in very rare cases disappear under high load. | We fixed the underlying issue that caused the data to disappear. |