Changelog

​

Changed

• PIVOT-14106 Improved performance of audit history filtering.

​

Fixed

• LIM-2182: The Atoti Python extension now supports connecting to a Limits server running on a different host or port. See the Python integration guide for how to configure the URL.
• LIM-2188: Fixed the Atoti Python UI extension getting stuck on a loading screen forever when the Limits server was unreachable, blocking login and the cube/home page even though the Atoti session itself was healthy. The extension’s LIMITS client is now always provided to the UI, using a fallback service descriptor when the server’s versions can’t be fetched, so a down or unreachable Limits server no longer prevents the rest of the application from loading.
• LIM-2237: Fixed limit structure creation failing validation with Server Name ... not in the list of current connections when the connected Atoti server’s catalog name differed from the configured limits.autoconfiguration.server-name. Remote cube discoveries were tracked by catalog name instead of the connection server name, so the lookup returned no server; they are now keyed by the connection server name.
• LIM-2266: Fixed bulk workflow actions (for example selecting several Six-Eyes limits and approving them together) failing with a database deadlock on SQL Server. Completing several workflow tasks at once ran them as concurrent transactions that contended on Activiti’s task and bookkeeping rows and deadlocked on ACT_RU_TASK (SQL Server error 1205). Task state-transitions (claim, assign, release, complete) now run sequentially, while the high-volume workflow start, deletion and read operations remain parallel to preserve performance.
• LIM-2268: DefaultLimitsAppCrudService now synchronizes all create, update and delete operations on the same monitor as the existing save* methods, so concurrent limit modifications (from triggers or the UI) can no longer interleave and corrupt the JPA/datastore writes.
• LIM-2285: Executing a workflow with an unknown task or action now returns a clear 400 Bad Request instead of an opaque HTTP 500 NoSuchElementException. Limits whose scopes are inconsistent within a structure are now caught during validation, with an error naming the conflicting limits and scope keys.
• LIM-2305: Fixed incident review actions of the new incident review workflow not enforcing permissions, which let a user without ROLE_PROCESS_INCIDENT or ROLE_LIMITS process incidents through the /workflow-service/execute-task-action endpoint.
• LIM-2319: Fixed notifications breaking after running for several hours, where streaming the stored notifications for a new subscriber while another thread published could fail with IllegalStateException: Accept exceeded fixed size. The notification store is now backed by a concurrent map.
• LIM-2320: Fixed the Limits Inventory “Pending Approval” count always showing 0 for limits awaiting six-eyes approval. The count only recognised the four-eyes INITIALIZED/EDIT statuses and ignored the six-eyes PENDING_FIRST_APPROVAL/PENDING_SECOND_APPROVAL (and update/deletion/changes) statuses; they are now all counted.
• LIM-2331: Fixed a data-access-permissions leak where a limit structure containing several limits with different scopes exposed all of its limits to a restricted user as soon as one of them was in scope. Structure visibility is unchanged (a structure is shown when the user can see at least one of its limits), but its out-of-scope limits are now removed from the returned structure so a visible structure no longer reveals limits the user is not entitled to.
• LIM-2332: Fixed attachment workflow variables being missing from the workflow history. When converting historic variable updates, the returned map was keyed by the raw variable name (with the internal file:// prefix) instead of the prefix-stripped user-facing name, so callers looking up an attachment by its name could not find it; the map is now keyed consistently with the other variable converters.
• LIM-2333: Fixed a data-access scope permission granted on a parent level of a multi-level hierarchy not granting visibility to limits scoped at a deeper level underneath it. contains_any/contains_all scope matching only inspected each scope location’s selected (leaf) level name, so a permission on, for example, Level 2=FICC did not match a limit scoped at Level 3 whose stored path contains Level 2=FICC; matching now considers every level in the nested path.

​

Security

• LIM-2313: Fixed a security issue where an uncontrolled server name passed when connecting to a limit server could be used to read arbitrary files from disk. Server names are now restricted to ANSI alphanumeric characters, spaces, ., -, and _.

​

Added

• LIM-2227: Added an implementation of the audit screen that uses the new workflow service.

​

Fixed

• LIM-2233: Fixed deletion of a limit failing on the connected Atoti server when one of its calculated members (“available amount” / “utilization %”) had already been removed by a concurrent measure refresh. The drop is now idempotent, so an already-removed member no longer raises a “does not exist” error or leaves the deletion workflow in error.
• LIM-2243: Fixed limit creation, update and deletion failing with a 409 ConflictException (You cannot delete this member because other members depend on it), which could make the whole application unusable, when a user-defined calculated measure depended on a Limits-created measure (“Available Amount” or “Utilization %”). Limits measures are now only created when missing and only dropped once their KPI no longer has any limit; a measure that another calculated member depends on is kept and the failure logged, instead of aborting the operation.
• LIM-2252: Fixed IndexOutOfBoundsException in the incidents SSE listener when processing datastore transactions, which could cause real-time incident updates to stop being pushed to the UI.
• LIM-2253 Limits: Improved the performance of limit operations for large applications with tens of thousands of limits, where operations could previously take 30s to 1min each.
• LIM-2256: Fixed a race when several limits are deleted concurrently, where two KpiCrudService.refreshKPIs() runs both tried to DROP the same orphaned KPI on the connected server, causing the second drop to fail with a 404 (NotFoundException) and the deletion to surface as HTTP 500. The refresh is now serialized and a 404 on DROP KPI is treated as a successful (idempotent) deletion.
• LIM-2259: Fixed new limit creation failing with LimitsCrudException: No value present when the new limit’s date range overlapped multiple existing active limits sharing the same structure, scope, and limit type.
• LIM-2264: Fixed the Limit Structure delete action remaining available in the UI when no live limits exist for that structure.
• LIM-2267: Fixed KPI measures not being correctly created for new workflow limits because KPIs were refreshed before the limits were added to the connected server’s cache.
• LIM-2274: Evaluating a limit whose value is 0 no longer fails to persist the incident. The utilization ratio (measureValue / limitValue) produced a non-finite value (Infinity/NaN) that the relational store rejected; it now resolves to 0 for a zero-value limit.
• PIVOT-14077: Fixed the ID of a deleted limit being re-issued to a subsequently created limit.

​

Changed

• LIM-2239: Scope strings now use backslash escaping for the reserved characters | = < > & + [ ] \, so level, hierarchy, dimension and member names containing any of these characters are preserved through a scope-string round-trip. Existing scope strings without backslashes parse unchanged. See the scope overview and advanced scopes pages for the escape rules.

​

Fixed

• LIM-2172: Member selection in limit scope sometimes does not allow to remove members. Switching between simple and advanced mode can lead to empty tiles being displayed.
• LIM-2215 Permissions: Fixed limit permission checks being silently ignored for users authenticated via SSO.
• LIM-2238: Fixed editing a limit’s attachment in the Six-Eyes approval workflow failing with a 500 Internal Server Error when re-saving the limit.
• LIM-2240: Fixed ScopeCacheService.refresh() throwing IllegalStateException: Duplicate key ... (attempted merging values X and Y) on every restart when the datastore contained two LimitStructures declaring the same scope keys in a different order. The in-process scope-id dedup in ScopeTupleGenerator now keys by the canonical (sorted) scope form, matching what ScopeCacheService.refresh() uses, so equivalent scopes share a single id instead of being persisted as two store rows that later collide.
• LIM-2241: Fixed the Add Limit button being incorrectly disabled when the structure’s history contained a deleted limit with an advanced scope, which prevented the creation of new limits.
• LIM-2242: Fixed KPIs not displaying on dashboards for limits with TOTAL_EQUALS / TOTAL_EXCEPT advanced scopes on multi-level hierarchies.
• LIM-2244 Temporary limits: Fixed temporary limit creation failing from the KPI Drawer when selecting a different member on a multi-level hierarchy.
• LIM-2251: Fixed Atoti Limits failing to start for applications with a very large number of workflows. Warming the workflow cache at startup previously fetched tasks one workflow id at a time and queried their variables with one bind parameter per workflow, which could exceed the database’s per-query parameter limit (such as SQL Server’s 2100-parameter cap) and fail with a “query too large” error. Tasks are now retrieved in a single bulk query and their variables are fetched in batches sized to stay under each database’s parameter limit.
• PIVOT-13934: Fixed an NPE on Limits startup when the content server held a calculated measure whose content was not readable by the Limits service account (for example a measure created by another user with restrictive owners/readers). Such measures are now skipped with a WARN log identifying the measure name and the reason (missing read permission, empty content, or directory entry).