Some of the auto complete controls on various masks returned incomplete search results. This behaviours has been fixed.
The performance of the context resolvers, mainly the organizational unit context, has been improved.
The Swiss UID response mapper had a wrong mapping. It mapped the active flag of the HR status to the active of organization units. Therefore companies without a HR entry could not be registered. This issue was fixed.
There is a new setting that allows you to specify specific backend servers to only run scheduled tasks. All other servers will only run fast-tracked tasks, coming from user interactions over the UIs. To take full advantage of this features, you should point your UI servers connection to those backend servers, that do not run scheduled tasks. Fore more details see here.
The name_key of an employment is now available in both the string expression designer and in the template dictionaries.
There is a new Permission API that can be used to read the provisioned permissions
Breaking Change: Ressource Assignment with the context “Current Core Identity” used to be provisioned without a context to the CoreOne Authentication service. To better suite the Permission API requirements, this behavior was changed and they now also have a context provisioned. This is only a breaking change if your application requests the roles_with_context scope. Instead of an empty context, you will now get the user itself as the context.
Support for MariaDB 10.9 and greater was added.
When installing the CoreOne Suite and it’s components, it’s now possible to define a read only connection string. That setting always existed in the config tables, but there was no option to set it from the installer. If you have a cluster, it’s advised to take use of this read only connection string.
The installer generates application secrets for all components and automatically sets them in the database. They are now displayed in the installer (as *****) and can be copied and saved in a password safe. When installing a second node, you will need to provide those passwords.
There is a silent installer available. When installing or updating an installation, a configuration file will automatically generated with the data added. You can use this file to auto update the installation afterwards.
Breaking Change: The installer does no longer create the itsense user on new installations, but creates an admin_account user. This user is also linked to a Core Identity and can be used to access all application parts. This user is also the owner of all default roles and resources after an installation. When updating an existing installation, this user is also created but does not have a password. Please make sure you have a personalized admin user to set a password for the new admin_account after the update. Also make sure, that the admin_account fulfils the LoA of the Admin UI and create appropriate network mask with special LoAs before the update. For example when login in from 127.0.0.1 username and password is enough.
A bug in the password validation implementation prevented the propagation of password changes over the connector. The bug has been fixed.
Groups where the groupOfNames objectClass was not on top of the list could not be handled correctly by the connector. The bug has been fixed.
Editing a delegations with the start date in the past resulted in an UI validation error immediately upon clicking edit. This issue has been resolved.
The Shop lists are now ordered alphabetically.
The session and error handling of the Self-Service Portal has been improved. Whenever one of multiple Self-Service Portal services is being restarted or recycled, the load balancing could send a user to a different server. In that case, some of the session states might not have been persisted yet, and the user might have experienced either an error or a logout. This behaviour has been improved.
It’s now possible to encrypt the workflow options stored in the database, so that any sensitive data within the workflows are protected beyond the database. This new setting can be activated via installer or in the configuration file.
All existing Workflow Entry Points from the legacy workflows have been implemented as next-gen workflows. You will find a full documentation here.
Various new Workflow Activities have been added. You will find a full documentation here.
There is now a logout button in the workflow dashboard and the user must have access the workflow admin resource and the administrator resource in order to access it.
Breaking change: The CoreIdentityUpdate workflow now uses the system_name of the attributes that were changed instead of the name of the attribute. Existing workflows have to be adjusted.