Skip to main content

​
6.2.2 to 6.2.3

​
Deployment of limit-process-expiry.bpmn

If you restrict where Activiti loads processes from (spring.activiti.process-definition-location-prefix), or do not deploy the processes/*.bpmn files of limits-starter, also deploy limit-process-expiry.bpmn. Otherwise, limits using a workflow of the workflow service never expire.

​
Four-eyes requester check moved to isCurrentUserTheRequester

In the default four-eyes workflow (limit-process-instance.four-eyes), LimitsProcessInstanceWorkflowService#roleValidation now calls the new protected method isCurrentUserTheRequester(LimitsProcessInstance) instead of isCurrentUserTheSameAsPreviousActor. The user who opened the pending request can no longer approve it, even after a rejection, and the rejecting approver can approve it later. See limit-process-four-eyes.bpmn. Action is needed only if your project:
  • overrides isCurrentUserTheSameAsPreviousActor to change who counts as the creator: move that logic to an override of isCurrentUserTheRequester. Other workflows still use the former.
  • relied on a creator approving their own limit after a rejection: another approver must now approve it, or set limits.workflow.workflow-rules.can-approver-be-same-as-creator to true, which disables the four-eyes rule.

​
DefaultLimitsFileLoadingService#createAsOfDateFile() removed

The protected method DefaultLimitsFileLoadingService#createAsOfDateFile() no longer exists. Subclasses of DefaultLimitsFileLoadingService that override it no longer compile: remove the override. By default, Atoti Limits still generates the as_of_date.csv file in limits.initial-load.root-dir when this file does not exist. The default file initial as-of-date provider, instead of the file loading service, now writes this file at startup. Deployments that do not override the method need no change. To adapt code that overrode the method:
  • To change how the initial as-of-date is produced, declare an ILimitsInitialAsOfDateProvider bean. With such a bean, Atoti Limits ignores the as-of-date file. See How to choose the initial as-of-date.
  • To stop generating the file, set limits.as-of-date.initial-provider to utc-time (the as-of-date file is then ignored) or none (the as-of-date file is also ignored, and the as-of-date must come from an ILimitsInitialAsOfDateProvider bean). See How does Atoti Limits choose the initial AsOfDate?.

​
Widening the mdx column of the incident table

This change affects persistent data mode only. You need to act on it only if saving incidents has failed because of the size of the mdx column. Widening the column is recommended if your limit structures are large enough to reach that size. Atoti Limits now maps the mdx column of the incident table with a length of 1,000,000 characters. Atoti Limits 6.2.3 starts against an existing incident table without any database change, including with Hibernate schema validation (hbm2ddl.auto: validate). Until you widen the column in the database, it keeps its VARCHAR(1000) type, and incidents whose evaluation MDX exceeds 1,000 characters still fail to be saved or updated. The evaluation MDX grows with every limit of a structure: about 16 single-level limits, or 5 to 7 limits scoped on several levels, are enough to exceed 1,000 characters. If your structures reach this size, widen the column. Schema managed with Liquibase The new Liquibase changeset limits-6-2-3-changelog-1.yaml widens the column to VARCHAR(1000000). Liquibase creates it as MEDIUMTEXT on MySQL and MariaDB, and as varchar(max) on SQL Server.
  • Shipped master-changelog.yaml: it already includes the changeset.
  • Custom master-changelog.yaml: add limits-6-2-3-changelog-1.yaml to it, after limits-4-2-0-changelog-2.yaml.
Liquibase does not run at startup in the shipped configuration (spring.liquibase.enabled is false in application.yml), so apply the changeset to the database explicitly, for example with mvn liquibase:update. See Migrate your schema. Schema not managed with Liquibase Change the type of the mdx column of the incident table to a character type that holds at least 1,000,000 characters, such as the long text type of the database. Apply this change with the schema migration process already in place for the database. To derive the SQL from the Atoti Limits changeset instead, see Case 3: Default schema without Liquibase.

​
Level path service deprecated

The REST service behind /services/rest/v1/levelPath, which the Atoti Limits Auto-Config modules add to the connected Atoti Server, is deprecated and will be removed in 6.3.0. Atoti Server 6.2.3 ships an equivalent service at the same path. The path, the requests and the responses are unchanged, so Atoti Limits and its UI need no change. Until you switch, the Auto-Config modules keep providing the deprecated service:
  • Atoti Server 6.1.x, or 6.2.x before 6.2.3: the server has no level path service. The deprecated service is used, and a message is logged at startup. No action is possible until you upgrade the server.
  • Atoti Server 6.2.3 or later: the server ships the service, but it is disabled by default. The deprecated service is used, and a warning is logged at startup.
To switch to the Atoti Server service, set these properties in the connected Atoti Server:
The Auto-Config modules then stop registering the deprecated service. Securing the endpoint works as before. When limits.autoconfiguration.security.enabled is true, Atoti Limits secures /services/rest/v1/levelPath whichever service serves it. Set atoti.server.endpoint.level-path.security.enabled to true to let Atoti Server secure it with its own role-based security filter chain instead. The LimitsConnectedServerSecurityAutoConfiguration.LEVEL_PATH_PATTERN constant is removed, and LIMITS_SECURED_PATTERNS no longer lists the level path. If your security configuration referenced either one for the level path, use the /services/rest/v1/levelPath path directly.

​
6.2.1 to 6.2.2

​
Support for 6.0.x and 6.0.x-sb3 Atoti Servers removed

Atoti Limits has removed support for connecting to Atoti Server 6.0.x and 6.0.x-sb3, which have reached end of support. This affects anyone using limits-auto-config-60 or limits-auto-config-60-sb3. The connected Atoti Server instance must be upgraded to 6.1.x or 6.2.x. For that upgrade, see the Atoti Server migration notes. After upgrading the connected server, switch the Maven dependency to the matching artifact:
  • For Atoti Server 6.1.x, use limits-auto-config-61.
  • For Atoti Server 6.2.x, use limits-auto-config-62.
For the current list of supported artifacts, see the compatibility matrix.

​
limits-common module removed

The limits-common Maven module no longer exists. Its classes keep their packages (com.activeviam.limits.core.shared.*) and now ship with the module that uses them:
  • limits-activeviam on the Atoti Limits server,
  • limits-integration-common on a connected Atoti Server (pulled in by limits-auto-config-<version>).
No project is expected to depend on limits-common directly, as it was already a transitive dependency of both. If your pom.xml declares it anyway, remove the dependency: the classes are available through limits-activeviam or limits-auto-config-<version>. Classes you override keep their fully qualified names, so no import changes are needed.

​
6.2.0 to 6.2.1

No migration necessary.

​
6.1.23 to 6.2.0

Atoti Limits now requires Java 25. Update your project to build and run with Java 25. Spring Security Kerberos is now published in the org.springframework.security group, and released with Spring Security itself. If your project declares a spring-security-kerberos-* dependency of its own, for instance to set up Kerberos machine-to-machine authentication, change its groupId to org.springframework.security and drop its version, which Spring Boot’s dependency management now provides. The 2.x releases of the retired org.springframework.security.kerberos group are compiled against org.springframework.security.crypto.codec.Base64, a class Spring Security 7 removed, so authenticating a request with them fails at runtime with java.lang.ClassNotFoundException. No code migration is necessary.