Upgrade to TAS 5.19 - Key Changes and Removed Features

What changes in the customer's configuration when upgrading from 5.17 to 5.19: templates, variables, workflows, calculations, prints and crons. Intended for TAS consultants who prepare the upgrade together with the customer and verify it after deployment.

Where the consultant comes in

Pre-upgrade template audit

Removed constructs in templates

Process graph

The process graph is no longer instance-based – it is computed dynamically and shows much more information than before.

Retranspiling calculations (only when upgrading from versions below 5.17.7)

In 5.19, filter, find, some, every, reduce and sort with an async callback are now rewritten into sequential loops; lodash methods are left untouched.

If you are upgrading from 5.17.x lower than 5.17.7, run the following after the upgrade:

validation.checkAsyncAwaitRetranspilationNeeded(tProcId?)

sys.retranspileCalculationsByProcessId(...)
sys.retranspileCalculationsByTaskId(...)
sys.retranspileGlobalScripts()

Plugins

The new plugins docx-generator (1.0.2) and helpDocs (1.0.5) have been added. All other plugins have new versions in 5.19, and the old versions silently fail to load – after the upgrade, verify that the customer has all of them.

Changes in workflows and the process graph

Changes in calculations and scripts

docxGenerator.generate() – changed contract

The function now returns a list [{name, id}] instead of a single DMSF_ID. A new saveAsPdf option has been added.

// 5.17
const dmsfId = docxGenerator.generate(...);

// 5.19
const result = docxGenerator.generate(...);
const dmsfId = result[0].id;

New script mapping (optional optimization)

The columns TEMPLATE_PRINT.PRNT_APPEND_SCRIPTS and TEMPLATE_TASKS.TTASK_APPEND_SCRIPTS have been added. Prints and dynamic conditions can therefore load only a subset of CO scripts instead of all of them.

New calculation functions to offer

The mandatory link setting has been removed

TTASKLINK_IS_MANDATORY has been removed end-to-end. A link marked as mandatory no longer blocks task activation on its own – activation is now purely Petri-net based.

This approach was used historically.

Babel 8 – stricter JSX checks in Case Overview and prints

Starting with version 5.19, TAS transpiles frontend scripts using Babel 8. This change tightens JSX syntax checking and may cause previously working Case Overview and print scripts to fail to save. The following section describes how to identify and fix affected scripts.

What the change affects

Only React scripts that are transpiled on the server side when saved:

• Case Overview,
• prints (prints / PDF).

Backend calculations, scripts, crons and dynamic conditions are not affected.

Cause

In JSX, an attribute may contain only one expression. If it contains multiple values separated by commas, it is a sequence expression. Babel 7 silently accepted this syntax and evaluated it to the last operand – discarding all preceding values without any warning. Babel 8 turns it into a hard compilation error:

Sequence expressions cannot be directly nested inside JSX.
Did you mean to wrap it in parentheses (...)?

How to identify an affected script

How to fix it

1. Open the script and go to the line given in the error message.
2. Find the attribute that contains comma-separated values.
3. Merge them into a single array or object.
4. Save the script and verify how the component behaves – after the fix, the previously discarded values take effect for the first time.

Incorrect:

additionalVariables={
    [{taskName: 'Confirm the delivery'}],
    [{taskName: 'Change the billing status'}]
}

Correct:

additionalVariables={[
    {taskName: 'Confirm the delivery'},
    {taskName: 'Change the billing status'}
]}

What to watch out for

• The fix changes behavior. Once the values are merged into an array, the component starts working with values it previously discarded. Verify that the result is actually what you want – this is not a purely cosmetic change.
• The pattern tends to be copy-pasted. It is rarely limited to a single attribute. Go through all Case Overview scripts and prints in the environment and look for any prop written as a comma-separated list of values.
• The error is reported by the server. Although this is frontend code, transpilation happens on the backend when the script is saved. You will therefore see the message as a save error, not in the browser console.

Crons from the consultant's perspective

Crons have been completely rebuilt. Most of the work falls to DevOps, but three things are up to you.

EWS mail crons will be deleted

Then transfer the configuration to MS Graph crons. New options you can take advantage of:

• clientSecret can be a reference to a Vault secret in the form {{vault:name}},
• the Discover folders button lists the mailbox's available folders,
• mailbox duplication for quickly setting up another cron.

Behavior changes the customer will notice

New crons

Existing instances already have the CRONS table populated, so seeding the default crons is a no-op. New crons must be created manually via Administration → Crons → "+", and they are inactive by default:

• DatabaseHealthReportCron,
• DatabaseIndexRebuildCron.

Discuss with the customer whether to activate them. Also set application.crons.consecutiveFailureThreshold (default 5) – after N consecutive failures, a notification e-mail is sent to the cron's error addresses.

What to communicate to the customer in advance

Changes that users will see or feel and that cannot be reverted.

New features to offer the customer

• Plugin docx-generator – DOCX generation has moved from the core into a plugin, and a new saveAsPdf option has been added.
• Plugin helpDocs – documentation directly in the application.
• Plugin Store – Administration → Plugins → Plugin Store tab (only when TAS_PLUGIN_STORE_URL is set). Install and uninstall plugins directly from the GUI.
• MCP endpoint – POST /mcp/:scenario? exposes TAS to external AI clients (Claude Desktop, Claude Code) in the scenarios case-creation, case-editing, case-lookup, knowledge, account and administration. API token only; every call is audited.
• E-mail via MS Graph – new msgraph transport (app-only / Client Credentials) alongside basic, oauth2 and sendmail.
• Custom X-headers in notifications – with placeholder support and an allowlist.
• System Health – fleet-aware monitoring of all instances with 48h history, plus Database Activity showing running queries.
• Plugin configuration in the GUI – Administration → Configuration → Plugins tab.

Consultant's post-upgrade checklist

Crons and integrations

• EWS crons moved to MS Graph, configuration from the log applied
• Manual run of key crons (Run manually) completes without errors
• The cron list matches the pre-upgrade state – active status and timing
• Sending e-mail works: notifications and reports
• DMS upload, fulltext and previews work
• AD/LDAP synchronization (AdSyncCron – fixed in 5.19; previously it silently synchronized nobody)

Plugins

• All expected plugins are loaded in Administration → Plugins (incompatible ones are silently skipped)