Skip to main content

2026.1 to 2026.2

1. ASYS_CALENDARLINK.ID column is now required​

What changed​

Starting with release 2026.1, the ASYS_CALENDARLINK table generally contains the ID column. Older systems sometimes omitted this column.

Why it matters​

Database scripts, custom integrations, and upgrade processes that work with ASYS_CALENDARLINK may rely on the presence of the ID column. Systems that were created with the older schema can therefore fail or behave unexpectedly if the column is still missing.

Review the schema of existing systems and add the ID column to ASYS_CALENDARLINK if it is missing.

2. Preferences: jditoScriptManagerNext removed​

What changed​

The jditoScriptManagerNext option has been removed from the available project preferences.

Why it matters​

Projects can no longer activate the legacy script manager by setting jditoScriptManagerNext to false. ScriptManagerNext has been the default for many years and has no known issues. The legacy script manager was therefore removed.

No action is required for most projects. ADITO Designer removes the jditoScriptManagerNext entry automatically when you open the project preferences after the upgrade. If your project relies on the legacy script manager for a known reason, please create a ticket.

3. onValidation return values handled consistently​

What changed​

Entity-level and EntityField-level onValidation processes now handle return values consistently. Boolean values and their string equivalents no longer receive special handling in Entity-level processes. EntityField-level behavior has not changed.

Why it matters​

An Entity-level onValidation process that returns true or "true" now causes validation to fail. A failed validation can prevent users from saving a record.

A validation succeeds only if the process returns no result, null, an empty string, or whitespace. Any other return value is treated as invalid. Invalid validations should return a clear text message that tells the user how to correct the input.

Developers must review and update Entity-level onValidation processes as described in the following table. EntityField-level processes do not require changes.

Existing Entity-level resultRecommended action
result.string("You did not specify any address information")Leave unchanged
result.string("")Leave unchanged
result.string(null)Leave unchanged
No resultLeave unchanged
result.string(true)Pass null or remove the result.string(...) call
result.string("true")Pass null or remove the result.string(...) call
result.string(false)Replace the value with a clear validation message
result.string("false")Replace the value with a clear validation message
note

The examples are simplified. Return a clear, actionable validation message and use the translation methods to provide the message in the user's language.

4. REST Webservices: Numeric input formats are now locale-independent​

What changed​

Numeric values submitted to REST Webservices are now always parsed using a locale-independent numeric format. Decimal values must use a period (.) as the decimal separator. Locale-specific number formats, such as decimal commas or grouping separators, are no longer interpreted.

Why it matters​

This can be a breaking change for integrations that previously relied on the ADITO Server locale or on a locale submitted with the request. For example, a server running with a German locale could previously accept locale-specific number formats such as 1,5. These values are no longer valid numeric input values because parsing no longer changes dynamically based on the active locale.

Review clients that write numeric values through REST Webservices. Make sure they submit decimal values with a period as the decimal separator, do not use grouping separators, and do not rely on server-side or request-specific locale settings for numeric input parsing. For example, submit 1.5 instead of 1,5 and 1234.56 instead of 1.234,56.

5. Calendar caching: ASYS_CALENDARBACKEND is no longer used for cached entries​

What changed​

Starting with ADITO 2026.2.0, calendar caching no longer stores or reads cached calendar entries through the ASYS_CALENDARBACKEND table.

Why it matters​

Custom SQL queries, integrations, and maintenance scripts that use this table as a source of cached calendar data no longer receive current cache entries after the upgrade. This change applies only to calendar caching; it does not remove the table.

Review custom SQL, integrations, and maintenance scripts that read or write cached calendar data in ASYS_CALENDARBACKEND. Update them so they no longer rely on the table as a calendar-cache data source.

6. PDF Preview Service: Preview generation is handled by a global service​

What changed​

The creation of preview images for ODT and DOCX files is now handled by the global PDF Preview Service. ADITO 2026.2 requires version 1.1.0 of the service (adito/pdfpreview-server:1.1.0).

Why it matters​

Older versions of the PDF Preview Service cannot generate previews for ODT and DOCX files with ADITO 2026.2.

For SSP and standard ADITO Cloud systems, ADITO Cloud provides the required service. No action is required for these systems.

For systems that are neither cloud-based nor managed, update the PDF Preview Service to version 1.1.0 (adito/pdfpreview-server:1.1.0) before or during the ADITO upgrade.

7. JasperReports and Groovy: Groovy is available for report definitions again​

What changed​

The JasperReports and Groovy versions used by ADITO have been updated.

Why it matters​

Groovy can be used again when defining reports.

No migration action is required. Use Groovy when defining reports where it is appropriate.

8. Handling Minimum and Maximum numeric Values​

What changed​

Minimum and maximum values are now validated consistently in both the frontend and the backend.

For fields with the content type NUMBER with defined minimum and maximum limits, the following rules apply:

  • Required (mandatory) fields must contain a value within the defined range.
  • Optional fields may remain empty. If a value is provided, it must be within the defined range.
  • The backend rejects values below the minimum or above the maximum with a validation error.

In addition, number values written through web services or JDito are no longer automatically adjusted to the defined minimum or maximum. Values outside the allowed range now result in a validation error.

Why it matters​

Previously, minimum and maximum values were validated only in the frontend. This caused two issues:

  • Optional fields were treated like mandatory fields, requiring users to enter a value even when the field was not required.
  • If the frontend validation was bypassed, values outside the allowed range could reach the backend without being rejected.

Backend validation now ensures that only valid values are accepted.

Since number values written through web services or JDito are no longer adjusted automatically, they must be within the defined range.

Target groupRecommended actions
Webservice-ClientsEnter values carefully and ensure that they are within the defined minimum and maximum limits. Values outside this range are rejected and are no longer corrected automatically.
DevelopersReview all affected processes, configurations, and integrations to ensure that they provide valid values. For optional fields, ensure that the database column allows NULL or configure a suitable valueProcess.

9. onValueChange processes: RECORD removed from onValueChangeTypes​

What changed​

The RECORD type is no longer available in onValueChangeTypes when configuring an onValueChange process in the ADITO Designer. Previously, this type could be used to react to values loaded with a record, although it did not work reliably. That configuration is no longer supported.

Existing RECORD types in the onValueChangeTypes configuration of entity fields do not trigger a process. The ADITO Designer ignores them and removes them when the entity is saved.

Why it matters​

Soon, initial values will no longer trigger onValueChange processes. Reacting to values that are loaded initially also provides little value and can cause unexpected behavior. Removing RECORD from onValueChangeTypes makes onValueChange processing more consistent and easier to understand.

Search entity fields for RECORD entries in onValueChangeTypes and remove them. To avoid individual changes when entities are saved in the ADITO Designer, remove all affected entries in bulk before or after the upgrade. Review affected onValueChange processes and adapt any logic that relied on reacting to initially loaded record values.