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-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