Changelog

• UI source code
• UI build
• Source files to build the module
• Maven repository required to build the project and run the tests.

​

Added

• PIVOT-14984: Added the limits.as-of-date.initial-provider property, which selects the source of the initial as-of-date: file (default, loads the date from the as_of_date.csv file, or creates this file with the current date if it does not exist), utc-time (current UTC date, as-of-date file ignored, no file generated) or none (no default, as-of-date file ignored, the as-of-date must come from an ILimitsInitialAsOfDateProvider bean).
• PIVOT-14984: Added the ILimitsInitialAsOfDateProvider interface. Declare a bean of this type to choose the initial as-of-date. A declared bean replaces the provider selected by limits.as-of-date.initial-provider, and Atoti Limits then ignores the as-of-date file.

​

Changed

• PIVOT-15374: The KPI measures that the Limits Auto-Config modules create in the connected Atoti server are now typed: the KPI status is an integer, the KPI goal is a double, and the KPI value has the type of its underlying measure. The type stays Object for a calculated measure, or when the underlying measure is not yet initialized when the KPI measure is.
• PIVOT-15406: Limits using a legacy workflow now expire with the same rules as the new workflow service, including capping the /expire date at the current as-of date, see Expire the workflow. Their temporary limits now expire too.
• PIVOT-15450: In the default four-eyes workflow (process limit-process-instance.four-eyes), LimitsProcessInstanceWorkflowService#roleValidation identifies the requester with the new protected method isCurrentUserTheRequester. Override it instead of isCurrentUserTheSameAsPreviousActor to change who counts as the requester in this process. Other processes still use isCurrentUserTheSameAsPreviousActor.

​

Deprecated

• PIVOT-14961: The REST service behind /services/rest/v1/levelPath is deprecated for removal in 6.3.0, replaced by an equivalent service shipped by Atoti Server 6.2.3 and later. To use it, set atoti.server.endpoint.level-path.enabled=true. See the Migration guide.

​

Removed

• PIVOT-14984: Removed the protected method DefaultLimitsFileLoadingService#createAsOfDateFile(). The default file initial as-of-date provider now creates the as_of_date.csv file with the current date at startup if this file does not exist. Subclasses that override the method must remove the override. See the Migration guide.

​

Fixed

• PIVOT-14984: When the as-of-date file contains several dates, Atoti Limits now starts with the latest one. Previously, it used the last date read, which depended on the order of the rows in the file.
• PIVOT-15251: Loading the limits data no longer fails with ActivitiIllegalArgumentException: key is null when a limit using a non-legacy workflow, such as the Six-Eyes Approval Process, is past its end date.
• PIVOT-15331: Limits using a non-legacy workflow, such as the Six-Eyes Approval Process, now expire once the as-of date passes their end date. A client that does not deploy every processes/*.bpmn file of limits-starter must also deploy limit-process-expiry.bpmn, see the Migration guide.
• PIVOT-15420: In persistent mode, deleting or expiring a limit that uses a legacy workflow, such as the Four-Eyes Approval Process, now saves its DELETED or EXPIRED status to the database. Previously, the limit kept its old status in the database, so after a restart of Atoti Limits or of the connected server it applied again and its resolved incidents went back to BREACHED. Limits already affected are not repaired by this fix.
• PIVOT-15420: In persistent mode, a user with ROLE_APPROVE_REJECT_LIMIT but not ROLE_UPDATE_LIMIT can now approve or reject a limit that uses a legacy workflow. Previously, saving to the database failed with an access denied error.
• PIVOT-15421: A limit using a legacy workflow that fails to expire no longer stops the expiry of the other limits. Each failure is logged with its limit id.
• PIVOT-15451: The Pending Approval column of the Limits Inventory now counts the limits awaiting approval on the FourEyes workflow. It showed 0 for these structures since 6.2.1.
• PIVOT-15454: A new notification subscription no longer misses its initial event at random, and closing it no longer throws a NullPointerException. With notification-service.initial-notification-mode=DONT_SEND, a subscription now starts with an empty INITIAL_EVENT, as documented, instead of an empty NOTIFICATION event.
• PIVOT-15394: In persistent data mode, incidents are now saved and updated when the evaluation MDX of their limit structure exceeds 1,000 characters. About 16 single-level limits, or only 5 to 7 limits scoped on several levels, were enough to reach this length: saving a new incident then failed, and an existing breach incident stopped being updated. Atoti Limits now maps the mdx column of the incident table with a length of 1,000,000 characters, and the new Liquibase changeset limits-6-2-3-changelog-1.yaml widens this column. Widening the column is optional: Atoti Limits starts without it, but these incidents still fail to save until the column is widened. See the Migration guide.
• PIVOT-15450: In the default four-eyes workflow, the user who created, edited or requested the deletion of a limit can no longer approve or reject that request, including after an approver rejected it, unless limits.workflow.workflow-rules.can-approver-be-same-as-creator is true. The approver who rejected it can now approve or reject it later. Previously, the creator could approve their own limit after a rejection, and the approver who rejected it was blocked because they were the last user to act on it.

• UI source code
• UI build
• Source files to build the module
• Maven repository required to build the project and run the tests.

​

Added

• LIM-2432: Added the limits.scope.allow-multiple-not-in-limits property. Setting it to false allows at most one “NOT IN” scoped limit per structure at a time. Defaults to true, preserving prior behavior.

​

Changed

• LIM-2361: The Approve and Reject actions of the default Six-Eyes limit approval workflow now include a Comment field, as in the Sign-off workflows.
• PIVOT-15183: Creating a limit scoped at the (Total) of the first level of a slicing hierarchy is now rejected from the UI, the REST API and CSV upload. A (Total) on a deeper level is still accepted. Existing limits, including those loaded at startup, still load, evaluate and can be updated.

​

Deprecated

• PIVOT-15188: IncidentEvaluator.evaluateIncidents without measure names is deprecated. It reads the KPI value from the limit’s measure, which is wrong for a TOTAL EXCEPT or TOTAL EQUALS scope. Use the overload that takes the status and value measure names selected by the MDX query.

​

Removed

• LIM-2438: The limits-common Maven module - which store duplicate classes shared by both Atoti Limits and the connected server - has been removed. Its classes, in the com.activeviam.limits.core.shared packages, now belong to limits-activeviam, while the connected Atoti Server keeps its own copies in limits-integration-common. Package and class names are unchanged. See the Migration guide.
• PIVOT-14850: Removed support for connecting to Atoti Server 6.0.x and 6.0.x-sb3. The limits-auto-config-60, limits-auto-config-60-sb3, limits-atoti-server-60, and limits-atoti-server-60-sb3 artifacts have been deleted.

​

Fixed

• LIM-2346: Fixed a limit scoped at a (Total) of a slicing hierarchy never being applied, leaving those rows with no limit status.
• LIM-2346: Fixed the scheduled evaluation never raising an incident for a limit scoped at the (Total) of the first level of a slicing hierarchy, whether the scope uses the AllMember or an aggregated operator (TOTAL EQUALS, TOTAL EXCEPT).
• LIM-2356: When a six-eyes workflow update or deletion is approved, any earlier workflow still active for that limit is now cancelled; the cancelled workflow is marked as superseded and keeps its audit history, so the limit’s original creation request remains visible in the audit trail.
• LIM-2442: A scheduled evaluation with limit failures sent the same Limits Evaluation Completed notification as a successful run, so failures went unnoticed outside the server log. The notification now reports the number of errors and its severity is raised to high when there were errors.
• LIM-2432: Creating limits on the same structure with overlapping dates and overlapping “for each in” scopes - for example a limit on Book in [A, B] and a limit on Book in [B, C] - would have passed but should not have been allowed.
• LIM-2433: Fixed a limit scoped with (Total) of selected or (Total) excluding selected on a multi-level hierarchy being evaluated over every member of the level. The members the scope selects or excludes were ignored, so a (Total) excluding limit was evaluated against the unfiltered total and breached on it; such scopes now aggregate only the members they select.
• PIVOT-15188: Evaluating a limit with a TOTAL EXCEPT scope failed with a NullPointerException and raised no incident. Such incidents now report the exposure without the excluded members.

• UI source code
• UI build
• Source files to build the module
• Maven repository required to build the project and run the tests.

​

Added

• PIVOT-14095: Added an opt-in security filter chain for the Atoti Limits REST endpoints of a Connected Server. Setting limits.autoconfiguration.security.enabled to true registers a SecurityFilterChain built with the Connected Server’s MachineToMachineSecurityDsl that accepts any authenticated request, so applications no longer need to write their own chain for these endpoints. The property is false by default and leaves existing applications unchanged. See the Auto-configuration properties reference.

​

Changed

• PIVOT-14310: The incident SSE subscription (GET /limits/sse/v2/incidents/subscribe/filter) and the notification service SSE subscription now carry X-Accel-Buffering: no and Cache-Control: no-cache, no-transform so that reverse proxies do not buffer or compress the event stream. A buffering proxy delivers the incident and notification updates only when the stream ends.

​

Removed

• PIVOT-14667: The Dependencies page has been removed from the release documentation because the dependencies are now aligned with the Atoti Server version. See the Atoti Server dependencies page for the underlying Spring Boot and Java versions.

​

Fixed

• LIM-2278: Fixed limit evaluation considering only the default member for scopes on a slicing hierarchy (no AllMember level); every matching member, including multi-level Total subtotals, is now evaluated.
• LIM-2346: Fixed a limit defined at the (Total) of a multi-level hierarchy’s first level (for example a dynamic tenor hierarchy) not applying to the Total row, which showed no limit status.
• LIM-2352: Fixed the Audit Screen reporting a spurious change (for example 100 → 100) when an unchanged numeric value was deserialized as a different numeric type, such as Integer and Double.
• LIM-2357: Fixed the connection request from an Atoti server timing out when the limits data load is slow, which made the server retry and pile up blocked threads on the Limits server. The limits data load now runs in the background, one load at a time per server, and the connection request returns immediately.
• LIM-2370: Querying a limit KPI (Goal or Status) on a recently created calculated measure would throw an IllegalArgumentException: Unknown measure contributors.COUNT.
• LIM-2171: Fixed Limit Structures with no Limits minting a duplicate Scope Value ID instead of reusing the existing “N/A” ID, which could crash the scope cache with a duplicate-key error.
• LIM-2366: Fixed the log filling with ERROR-level stack traces for every AccessDeniedException, which now logs at DEBUG while other exceptions still log at ERROR.
• LIM-2365: Fixed the Mismatch for scope locations error not naming which limits caused a limit structure to fail loading; it now names the structure, the two limits, and the missing level.
• LIM-2428: Fixed querying a limit KPI (Goal or Status) throwing a NullPointerException when the as-of date fell outside the date range of the limits covering the queried location.
• LIM-2355: The Audit Screen showed no entry for a breach review, or for any other workflow task completed on the new workflow engine, leaving only the object’s creation entry.
• LIM-2357: Saving a limit took several minutes for a user with scope restrictions. The permission check loaded the whole limit inventory and re-resolved the user’s accessible scopes for every limit in it; it now looks up only the submitted limit and reuses the resolved scopes until a scope is added or removed. An existing limit outside the caller’s scope is also no longer mistaken for a new limit, so updating it requires the update permission rather than the creation one.
• LIM-2358: Workflow buttons - such as “Approve”, “Reject” and “Review breach” - were enabled for users without permission to approve/reject limits or process incidents, which failed with an “Access Forbidden” error on click instead of being disabled.
• LIM-2388: Approving an update or deletion of a limit that already had an attachment failed with an error and could leave Atoti Limits unable to restart.
• LIM-2439: Deleting a limit did not stop its KPIs from being evaluated on the connected Atoti Server until that server was restarted.
• PIVOT-14979: Uploading a CSV file that creates a large number of limits failed with a database parameter limit error.
• PIVOT-15169: When the two Six-Eyes approvers entered different comments, the Audit Screen showed the second comment as a change of the first one. Values entered in a workflow action’s input fields, such as Comment, are now shown as entered on each task.
• PIVOT-15170: When the two Six-Eyes approvers entered the same comment, the second approver’s comment was missing from the limit’s history and from the Audit Screen.

​

Security

• UI source code
• UI build
• Source files to build the module
• Maven repository required to build the project and run the tests.

​

Added

• LIM-2228: Added a first-class Atoti Limits plugin for the Atoti Python SDK (atoti-limits), replacing the existing Atoti Limits Python extension as the way to connect an Atoti Python session to a running Atoti Limits server.
• LIM-2350: Fixed a limit’s ID being reused by a new limit created with the same scope after a restart, which merged their audit histories. New limits no longer reuse a soft-deleted limit’s ID, so their audit histories stay separate.

​

Fixed

• LIM-2364: Fixed creating a limit structure on a recently created calculated measure failing validation with Measure ... not in the list of measures for the cube.
• LIM-2348: Fixed the audit history and decision buttons failing to open for expired, deleted-and-recreated, or fully-approved six-eyes limits. Those steps now simply show no available actions.