For the list of changes and fixes covered in this release, see the Changelog.
For information on upgrading from previous versions, see the
Migration guide
2026-10-29
Summary
Improvements- Choice of the initial as-of-date
- Incidents with MDX queries greater than 1000 characters are now persisted
- Typed KPI measures in the connected Atoti Server
- Level path service deprecated
- Bug fixes and performance improvements
Improvements
Choice of the initial as-of-date
The newlimits.as-of-date.initial-provider property sets the source of the as-of-date that Atoti Limits starts with.
By default, Atoti Limits still reads the as_of_date.csv file and creates this file with the current date if it does not exist.
Set the property to utc-time to start with the current UTC date at each startup: Atoti Limits then ignores the as-of-date file and generates no file.
To compute the initial as-of-date in code, declare an ILimitsInitialAsOfDateProvider bean. With such a bean, the as-of-date file is also ignored.
Set the property to none to rely on such a bean only: Atoti Limits then uses no default provider and also ignores the as-of-date file.
For details, see How does Atoti Limits choose the initial AsOfDate?.Incidents with MDX queries greater than 1000 characters are now persisted
In persistent data mode, Atoti Limits now saves and updates the incidents of limit structures whose evaluation MDX exceeds 1,000 characters. Previously, themdx column of the incident table held
at most 1,000 characters, a length that about 16 single-level limits, or 5 to 7 limits scoped on
several levels, reach. New incidents then failed to save, and breach incidents stopped updating.The fix takes effect once the mdx column of the incident table is widened. See
Widening the mdx column of the incident table.Typed KPI measures in the connected Atoti Server
The KPI measures that Atoti Limits creates in the connected Atoti Server now have a type. 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 staysObject for a calculated measure, or when the underlying measure is not yet initialized.Level path service deprecated
The REST service behind/services/rest/v1/levelPath is deprecated and will be removed in 6.3.0.
Atoti Server now ships an equivalent service. Atoti Limits still provides the deprecated service automatically.
It logs a message whenever it detects that the service of the connected Atoti Server is missing or not enabled.
To use the Atoti Server service instead, set atoti.server.endpoint.level-path.enabled to true.
Set atoti.server.endpoint.level-path.security.enabled to true as well to use its default security filter chain.
Both properties are false by default.
See Level path service deprecated.Bug fixes and performance improvements
- Limits using a legacy workflow, such as the Four-Eyes Approval Process, now expire with the same rules as the new workflow service. Their temporary limits now expire too. See Expire the workflow.
- Limits using a workflow of the new workflow service, such as the Six-Eyes Approval Process, now expire once the as-of date passes their end date. Some projects must deploy an extra process file: see the Migration guide.
- Loading the limits data no longer fails when a limit using a new workflow is past its end date.
- A limit using a legacy workflow that fails to expire no longer stops other limits from expiring.
- In persistent mode, deleting or expiring a limit that uses a legacy workflow now saves its status to the database. Limits already affected are not repaired.
- In persistent mode, a user who can approve and reject limits but cannot update them can now approve or reject a limit that uses a legacy workflow.
- The Pending Approval column of the Limits Inventory now counts the limits awaiting approval on the
FourEyesworkflow. It showed 0 for these structures since 6.2.1. - A new notification subscription no longer randomly misses its initial event, and closing it no longer fails.
- With
notification-service.initial-notification-mode=DONT_SEND, a subscription now starts with an emptyINITIAL_EVENT, as documented. - When the as-of-date file contains several dates, Atoti Limits now starts with the latest one.
2026-09-30
Summary
Improvements- Opt-in cap on NOT IN scoped limits per structure
- Comments on Six-Eyes approve and reject actions
- End of support for Atoti Server 6.0.x and 6.0.x-sb3
- Bug fixes and performance improvements
Improvements
Opt-in cap on NOT IN scoped limits per structure
A new property caps the number of “NOT IN” scoped limits a limit structure can have at once. Settinglimits.scope.allow-multiple-not-in-limits to false allows only one such limit per
structure. The property defaults to true, which keeps the previous behavior.Comments on Six-Eyes approve and reject actions
The Approve and Reject actions of the default Six-Eyes limit approval workflow now include a Comment field, matching the Sign-off workflows.End of support for Atoti Server 6.0.x and 6.0.x-sb3
Atoti Limits no longer supports connecting to Atoti Server 6.0.x or 6.0.x-sb3, which have reached end of support. Anyone still connected to one of these versions must upgrade to Atoti Server 6.1.x or 6.2.x. See the Atoti Server migration notes for that upgrade. Then follow the Migration guide to switch Atoti Limits to the matching artifact.Bug fixes and performance improvements
- A limit scoped at the
(Total)of a slicing hierarchy is now applied, instead of leaving those rows with no limit status. - A limit scoped to
(Total)of selected or excluding selected members on a multi-level hierarchy now aggregates only those members, instead of the whole level. - A scheduled evaluation now raises an incident for a limit scoped at the
(Total)of a hierarchy’s first level, regardless of the scope type. - Approving a Six-Eyes update or deletion now cancels any other active workflow for that limit, marking it as superseded while keeping its audit history.
- A failed scheduled evaluation now sends a notification reporting the number of errors, with severity raised to high so failures are not missed.
- Creating two limits on the same structure with overlapping dates and overlapping scopes, previously allowed, is now blocked as expected.
2026-09-03
Summary
ImprovementsImprovements
Opt-in security for the Atoti Limits endpoints
A Connected Server can now opt in to a ready-made Spring Security filter chain for the REST endpoints that Atoti Limits adds to it, instead of writing a custom one. Enabling thelimits.autoconfiguration.security.enabled
property registers a chain covering connection management, limit retrieval, and limit change events, built with
the same machine-to-machine security as the Atoti Server endpoints and requiring every request to be
authenticated. Existing applications are unaffected, since the property defaults to disabled.Bug fixes and performance improvements
- Incident and notification event streams are no longer buffered or compressed by reverse proxies. Real-time updates are now delivered as they happen, instead of only once the stream ends.
- Limits scoped to a slicing hierarchy now evaluate every matching member, including multi-level
(Total)subtotals, instead of only the default member. - Limits at the
(Total)of a first level of multi-level slicing hierarchy now appear in the UI. - The Audit Screen no longer reports a spurious change (for example
100 → 100) when a numeric value has not actually changed. - The Audit Screen now records breach reviews and other workflow actions, not only the initial creation entry.
- Creating a limit structure with no limits no longer risks an application error.
- Querying a limit’s Goal or Status no longer fails with an error when the requested date falls outside the limit’s date range.
- Approving an update or deletion of a limit with an attachment no longer fails with an error. This error could previously leave Atoti Limits unable to restart.
- Workflow buttons (“Approve”, “Reject”, “Review breach”) are now disabled for users without the required permission, instead of showing an “Access Forbidden” error after being clicked.
2026-07-27