Aurachain v3.15.0

Here’s What’s New in Aurachain v3.15

What’s new?

New capabilities for the Interface Builder

The “Data Grid” component received a few important updates:

The onSave and onSubmit events are now executed asynchronously if the error variable returns a promise. If the promise is rejected, the action will fail and any message returned will be displayed to the user. If the promise is resolved, the outcome of the event now depends on the message sent with the resolve action:

• if message is false or not set, the save/submit would succeed.
• if message is a string, the save/submit will fail and that message will be used to notify the user.
• if message is true, the save/submit script would be failed with a default message.

New methods are now available

Other improvements

• To save vertical space, helper text on UI components can now be hidden under a icon.
• The input area of the scripting editor can now be expanded to fill screen width.
• The text box component now allows number formatting irrespective of data model mapping. This means that number formatting will now also work on strings.
• Buttons added on segment components are now aware of index, path and parent parameters.
• Users can search for a specific interface or fragment using the search box above the page list.
• The full names of fragments can be displayed by hovering over the fragment’s name

Document Builder Enhancements

Dynamic tables can now be used in embedded blocks to display list child attributes.

Custom table & cell styles can now be configured on both static and dynamic tables.

Call API activity Enhancements

Starting with Aurachain v.3.15, app creators can further customize the definition of the Call API activity within the Diagrams module. Custom defined parameters can now be added as part of the ‘Custom Header’ area.

We have reorganized the Configuration section so that it accommodates the Custom Header area.

Here users will be able to add a new parameter by defining its name and linking it to:

• A data model variable
• A system variable
• Custom data defined from the ‘Custom Data’ section

The Custom Header area can be defined for both the Request and Response areas. However, for the Response area, a parameter can only be linked to variables from data model.

The Custom Header functionality cannot be used with neither System APIs nor WSDL APIs. Custom Headers are only available for SWAGGER APIs.

SSO Improvements

Single-Sign-On is becoming the preferred way of authenticating users in modern organizations.

However, just because a user has a valid SSO account, doesn’t mean they should be able to log into Aurachain. Therefore, admins can now toggle off the automatic provisioning of External accounts for users that authenticate via SSO. External accounts that have already been created can now be disabled.

Furthermore, in case the e-mail address of a SSO user changes, admins can now update the e-mail address of External users in order to maintain the connection between the two accounts.

Finally, the “new account” e-mail template now looks different for new External users, explaining that they can log in via the configured SSO provider.

User Management Improvements

In this release, we’ve simplified user statuses. Starting with v3.15:

• Platform users can be either Enabled or Disabled. The Inactive status no longer applies to these users and all such Inactive users will become Disabled instead.

• External users that authenticate via SAML or LDAP can be either Enabled or Disabled. The Inactive status no longer applies to these users and all such Inactive users will become Disabled instead.

• External users that authenticate via the legacy LDAP/AD integration can be either Enabled or Inactive. Inactive represents users that can no longer be found in the LDAP directory. The Disabled status no longer applies to these users. The status of these users cannot be changed.

If a user is Disabled, they will be logged out and unable to log in again. The user is still part of Groups and maintains all assignments and permissions. However, any tasks claimed by the user will be unclaimed and they will not receive any notification e-mails as long as they are Disabled. Once Enabled, the user can continue working as before. To make it easier for app creators and admins to identify these users, we’ve visually differentiated Disabled or Inactive users throughout the platform.

Finally, we’ve improved the “Bulk invite” functionality so that invited users can be directly provisioned before they confirm their accounts.

GDPR – Personal Data and Anonymization

GDPR requests or requirements involving anonymization can be tedious and time-consuming because they require identifying and removing all instances of relevant personal data. To make this task easier, we’ve introduced the ability to mark any attribute in an Application’s Data Model or in the Global Data Model as “Personal Data”. From the Process Inspector, admins can then select an instance and remove the contents of all “Personal Data” attributes with a single click.

Software Libraries Page

Aurachain – like most web applications – relies on many common open-source libraries. These libraries empower Aurachain to deliver state-of-the-art functionality while adhering to established best practices and technical standards.

In the spirit of transparency, and as a sign or recognition towards the great work the communities behind these libraries are doing, we now list all of these libraries in a dedicated “Software licenses” (or libraries?) page accessible via the Workspace menu.

Other Improvements

• The platform version and build number are now shown at the bottom of the Workspace menu.

• Admins can now explicitly enable or disable platform-wide Work Schedules depending on their needs. In the next version, we will introduce the ability for app creators to define specific Work Schedules per application, independently from admins.

• A new feature was added to the Global Data Model where users can select multiple data rows for deletion. Of course, the option comes with responsibility so the users must confirm the action beforehand.