. . .

Version 3.2.1

Remarkable changes

Remarkable changes do not affect system stability after ApiOMat upgrade, but may require changes in configuration, apps, or modules in the next development cycle.

Server side attribute validation

When using a collection attribute, the regex as well as min and max length validation is now executed for each element of the collection instead of the collection as a whole.

This only affects you if you're using regex or min/max length values for validating attribute values. Existing data is not changed at all and neither the returned data when fetching objects. But when creating or updating objects the new validation rules are followed.

TypeScript SDK

toJson() method in AbstractClientDataModel was renamed to toJsonString()

toJson() will now return a JSON-Object of the AbstractClientDataModel with all of its data

Dynamic Roles

When using Dynamic Roles, the custom role check (a.k.a. overwritten isUserInRoles() method in Native Module) was not called for ApiOmat's Customer objects since 3.1.1 . Since 3.1.4 the custom role check is executed for Customers, again.

You may be affected, if you implemented your own isUserInRoles() method that should be called for Customer requests assumed that the role class is assigned to a MetaModel. The isUserInRoles() method will now be called for Customers credentials again, like it is supposed to.

AOM.checkRoles() method

The basic user roles have always been hierarchical, which means for example that a user with the grant role could also read and write the object, and a user with the write role could also read the object. AOM.checkRoles() didn't adhere to this hierarchy, but instead lead to an authorization error when for example a user had write permissions and wanted to read an object. This was fixed.

AOM.checkRoles() is usually only required when combining custom auth methods with existing basic user roles. If you're using this method and didn't take the role hierarchy into account, you should revise your auth handling.


We switched from Oracle JDK 8 to AdoptOpenJDK 8.

On Windows, when installing the JDK with the ApiOmat installer, the JDK installation path was previously "C:\Java\jdk8" (independent of the exact version), and now it depends on the OpenJDK version, for example "C:\Java\jdk8u202-b08", with a slightly changed subdirectory structure.

To copy the old Java keystore to the new location you can run the following command (only necessary when you changed the keystore):

copy "C:\Java\jdk8\jre8\lib\security\cacerts" "C:\Java\jdk8u

All changes in the current and previous versions can be found at the root page.

All deprecations and their removal date can be found at Deprecations and Migration.