Release notes

setup push now updates the configuration in a single transaction, so a setup pull run at the same time no longer loses the configuration or the license.

setup push no longer deletes the licenses from the database when the platform_conf/licenses folder is missing.

Reading or writing the platform configuration now times out after 60 seconds by default, instead of waiting indefinitely. Change it with the new property bonita.platform.setup.transaction-timeout (for example 90s):

The value of bonita.platform.setup.transaction-timeout must be at least 1 second: 0 does not disable the timeout.

Generic file upload widgets and forms now restrict uploaded files to a default whitelist of common business file extensions (pdf, doc, docx, xls, xlsx, ppt, pptx, txt, csv, json, jpg, jpeg, png, gif, bmp, xml, msg, eml, tif, tiff, odt, ods, odp, zip), and reject files whose declared content type or, for binary formats, file signature does not match their extension. Binary files whose content matches their extension are accepted whatever their declared content type (for example application/octet-stream, sent by clients that do not recognize a file type), except types that a browser can execute.

The content type check applies to every file upload, including the .xml files of the administration imports (organization, actor mapping, profiles, applications, BDM access control). See Content type and content verification.

The whitelist can be customized, or opened to any extension with *, using the form.attachment.allowed.extensions property in the console-config.properties file. See Document allowed file extensions setting.

Rejected uploads are logged as warnings in the server log. See Rejected uploads.

The Hazelcast member embedded in Bonita now accepts other Hazelcast members only, on a single node as in a cluster. Hazelcast clients, Management Center included, are refused, and the Hazelcast REST API, health check included, and Memcache are no longer served. Nothing in Bonita uses them. If your deployment uses any of them on purpose, set bonita.platform.hazelcast.client-protocol.enabled=true in bonita-platform-sp-custom.properties, with the same value on every node of a cluster, and restrict port 5701 to the hosts that need it. See Allow communication between servers.

Bonita now writes one JSON event per login, failed login and logout to an audit log, so that a SIEM can collect who authenticated, when and from where: in server/logs/audit.log in the Tomcat bundle, and on the standard output in the Docker image, where the new AUDIT_LOG_STDOUT_ENABLED and AUDIT_LOG_FILES_ENABLED environment variables, like the access logs ones, also write them to a file or switch them off. The audit log is on by default. If you reuse a log4j2-appenders.xml customized for an earlier version, add the audit appenders and logger of the default file to it. See Audit log.

In the Docker image, the color reset of the console log lines now ends each line instead of starting the next one.

Hazelcast, the library used by the Cluster feature, is updated from 5.4.0 to 5.7.0. If you run a cluster, read Updating a cluster to 2027.1-u0 before updating.

Security hardening of the Hazelcast member. Two properties are involved, one per deployment mode.

The Hazelcast member embedded in Bonita accepts other Hazelcast members only, on a single node as in a cluster. Hazelcast clients, Management Center included, are refused, and the Hazelcast REST API, health check included, and Memcache are no longer served. Nothing in Bonita uses them. If your deployment uses any of them on purpose, set bonita.platform.hazelcast.client-protocol.enabled=true in bonita-platform-sp-custom.properties, with the same value on every node of a cluster, and restrict port 5701 to the hosts that need it. See Allow communication between servers.

No configuration change is required. The update introduces new cluster properties, all with default values, so nothing needs to be added to your configuration. See Work recovery when a node leaves the cluster if you want to tune them.

Work recovery is more robust. The recovery of a departed node’s work runs in the background instead of on a Hazelcast event thread, gives up on its own before its lock expires, and is tried again at the next departure or start for whatever it could not take over. A node that resumes after a tenant pause now resubmits the work that arrived while it was paused, which previously waited until the node left the cluster.

Clusters updated from an earlier version log a warning about the configuration schema at every start. Fresh installations do not. The message reports that the Hazelcast schema location is incorrect and that the default is used instead. It is harmless: your stored configuration still refers to the schema of the previous version, and the update does not rewrite it. To make it stop, update the version in the schema location in platform_engine/hazelcast.xml with the platform setup tool.

Two diagnostics change. The Number of locks column of the Hazelcast statistics file now counts the locks currently held on the node that writes the file, where it previously counted lock objects across the cluster, so expect a different magnitude and a value that varies with load. A lock whose lease expires before it is released is now reported as an error instead of a warning; if you raise alerts on errors from the cluster lock service, you may start seeing them for a condition that was already being reported at a lower level.