Upgrade notes (3.0 to 3.1)
To upgrade Optimize to version 3.1.0 please perform the following steps: Migration & Upgrade Instructions.
Here you will find information about:
- known issues,
- changes in the supported environments,
- any unexpected behavior of Optimize (e.g due to a new feature)
Changes in the supported environments
With this Optimize version there are also changes in the supported versions of Camunda BPM platform.
Camunda BPM platform
Optimize now requires at least Camunda BPM
See the Supported Environments sections for the full range of supported versions.
With Optimize 3.1.0 the History Cleanup configuration got restructured and needs to get adjusted accordingly.
Major changes are the removal of the global feature flag
historyCleanup.enabled in favor of entity type specific feature flags as well as a relocation of process and decision specific configuration keys. Best refer to the configuration reference.
Event Based Processes - Event counts/suggestions
As part of the upgrade from Optimize 3.0 to 3.1, the event counts and the next suggested events used as part of the event based process feature are recalculated. Until the recalculation is complete, the event counts might be incorrect and the suggestions inaccurate. Once the recalculation is complete, the event counts will return to being correct and you will see more accurate suggested next events.
With Optimize 3.1, user and group related permissions are checked by Optimize to determine whether the current user is authorized to access other users/groups within Optimize, for example when adding new roles to a collection. Due to this it is now required to explicitly grant users the relevant authorizations, otherwise they will not be able to see other users and groups in Optimize. More information on authorizations can be found here.
User Operations Log Import
With Optimize 3.1, the user operations log is imported to detect changes to running instances’ suspension status. The user operations log informs Optimize when instance suspension requests have been received by the engine, and Optimize then reimports the relevant instances to ensure their suspension state is set correctly in Optimize.
However, if instances are suspended using the engine API’s
executionDate parameter, with which suspension operations can be triggered with a delay, Optimize currently is not able to detect this delay, and will re-import the running process instances at the time the suspension operation is read from the user operations log, not at the time the suspension takes place. This can lead to inaccuracies in the suspension state of process instances in Optimize.