Release Notes for Q3 2024 and Q4 2024

For better clarity, we have modified some labels on the Data Pipeline Studio home page:

In a data visualization pipeline, if the configuration of the data source (such as data lake or analytical data store) changes, the Qlik Sense node shows a warning icon with hover-over text Configuration Changed. When you click the Qlik Sense node, a message appears in the side drawer notifying the user of the change and providing guidance on the action to be taken.

Previously, all ML algorithms triggered from Lazsa Data Pipeline Studio (DPS) were executed via a shared Jenkins job within the Lazsa-Core-Jobs folder.

Now, a dedicated run-ml-algorithms job is created for each stage within a product feature, enabling stage-specific execution of ML algorithms.

The new job structure improves organization, with jobs located at: Dashboard > Product-Release-Feature folder > Stage Name folder > run_ml_algorithms folder.

This enhancement ensures better management and separation of build jobs across stages.

As an administrator of the connection configurations of data tools (databases, data warehouses, and data integration and data visualization tools), you can now manage who can use the configuration in a data pipeline.

The Manage Access option for such a configuration now includes two new tabs: Teams with Access and Users with Access. These tabs provide a list of users and teams having read access to the specific configuration. Only these users and teams can use that data tool in a data pipeline.

• Scenario 1
  When a user is removed from a product and is not part of any other product, their permissions for data tools for that product (such as Databricks, Snowflake, and Qlik Sense) are automatically revoked.

• Scenario 2
  If the user is part of multiple products with the same role, a message is displayed listing the products to which the user belongs.

The search functionality is improved with the introduction of filters on the configurations of data tools. With this functionality, you can filter configurations based on the following:

• Added By

• Added Between

• Datastore Type

• Datastore Sub-Type

• Active or Inactive Datastores

• Datastores that I can use in data pipelines

• Requests for access to be approved by me

• Access requests made by me

The Develop screen of a product currently displays a list of all the tools and technologies used in that product.

A new dropdown list is added, displaying all available data pipelines for the product. When you select a pipeline from the list, only the tools and technologies used in that specific pipeline are displayed on the Develop screen.

Fault tolerance is introduced for data pipelines. The following options are available for this feature:

• Default - If a node fails, subsequent nodes go into a pending state. The pipeline status is seen as Failed.

• Skip on Failure - If a node fails, subsequent nodes are skipped from execution. The pipeline status is seen as Successful (with fault tolerance).

• Proceed on Failure - If a node fails, the subsequent nodes are executed. The pipeline status is seen as Successful (with fault tolerance).

This feature ensures that business processes relying on timely and accurate data are not hindered by unexpected issues.

Data Pipeline Studio now supports the Undo and Redo options for data pipelines in the draft state and the Reset option for data pipelines in the saved or published state.

• Undo– This option removes the last change done to a pipeline in the draft state.

• Redo– This option restores the last undone change in a pipeline in the draft state.

• Reset– This option reverts a pipeline to its last saved version that is not published or to its last published version.

Accepting the End User License Agreement (EULA) is now a mandatory step when you sign in to your Lazsa account for the first time. Access to platform features is restricted until you accept the EULA.

This feature is enabled by default on the new Lazsa tenants created after this release but disabled by default for your existing tenants. To enable this feature for your existing tenants, contact lazsa-support@calibo.com.

The platform audit logs now capture events related to tool connection configurations, including access requests, approvals, declines, and administrator changes.

This enhancement improves visibility, accountability, and security for configuration access management activities.

As a policy template creator or administrator, you can now view which products and portfolios are using your policy template in the Lazsa Platform. To access these details, click the ellipsis (...) in the template details row and select Usage Details from the dropdown menu. On the Policy Template Usage Details screen, view the list of products and portfolios on the respective tabs.

Also, while deleting a policy template, if it is in use by any product or portfolio, you are prompted to review its usage details. You must first dissociate the template from all associated products and portfolios before proceeding with deletion.

This enhancement improves visibility and ensures proper management of policy templates.

The Usage Details feature has been enhanced to provide better visibility into tool utilization. On a tool's connection configuration tile, click Usage Details from the ellipsis (…) menu to view the list of products and policy templates where the tool is used.

This support is newly added for the following tools:

• Terraform: Usage details provide the list of products, features, stages, and policy templates in which the Terraform configuration is used.

• Secrets Management Tool: Usage details provide the list of saved configurations where the tool is used for secret retrieval.

We have enhanced usage details for Jira, Confluence, and Qualys. Previously, only policy templates were listed. Now, usage details also include a list of products where these tools are used.

These enhancements provide deeper insights into tool usage, improving management and tracking.

If you have configured Azure Active Directory (AD) as the identity provider for single sign-on (SSO) for the Lazsa Platform, you can assign and manage users in a product team by using Azure AD groups. You can also manage tools access provisioning by using Azure AD groups.

All you need to do is, create a new team in Lazsa. Add your existing Azure AD groups to this team and map a product role to each AD group. Alternatively, add members to the team and assign a product role to each member. Lazsa automatically creates corresponding AD groups per role in Azure Active Directory, grouping users with the same role into one AD group. Roles determine tool access and permissions for users in the AD groups.

After you add the team to a product in Lazsa, access provisioning is managed by associating Azure AD groups with the tools. When Lazsa creates tool-specific objects for the product, the Azure AD groups added to the team are integrated into the tools and access is automatically granted as per the permissions defined in the assigned product role s. You can view tools access provisioning status and mapped roles for AD groups, troubleshoot provisioning errors, and track audit logs of all provisioning events.

Currently, the following tools are supported in this feature:

• Bitbucket Cloud

• Bitbucket Server

• GitHub Cloud

• GitHub Enterprise Server

• GitLab

• Confluence

• Jira

• Jenkins

• JFrog

• JFrog Cloud

• SonarQube

• Databricks

• Snowflake

• Qlik Sense

This feature is disabled by default. To enable it for your Lazsa tenant, contact us at:
lazsa-support@calibo.com.

The product deletion flow in Lazsa has been improved for better clarity and control. When deleting a product, you can now view all associated resources—such as source code repositories, CI/CD pipelines, cloud instances, or Terraform runs—per feature. You can choose to delete these resources from their respective tools or retain them.

If any errors occur during deletion, detailed error messages are displayed next to the affected resource. This helps you identify and resolve issues.

Lazsa now supports an approval workflow for promoting deployed technologies from one environment to another. When this workflow is enabled, technology can be promoted only after a promotion request is thoroughly reviewed and approved by a designated approver. Promotion requests can be sent for individual technologies or to promote an entire stage based on your project requirements.

This feature enhances governance by providing greater control over the promotion process and ensures compliance with organizational policies, reducing the risk of unauthorized or unreviewed changes across environments.

The following enhancements are done to the user offboarding process to provide better visibility, control, and automation:

• Transferring Ownership Before Offboarding
  If the user being offboarded is the sole owner of one or more products and portfolios, a list of those products and portfolios is displayed. You must assign at least one other user as an owner before offboarding the existing owner.

• Access Removal Options
  If the user is part of a product and not the sole owner, you can do either of the following:

  Completely remove the user from the product, which automatically revokes access to all associated tools.

  Retain the user within the product and revoke access to all associated tools.

• Team Membership
  If the user is part of teams that are not associated with any products, such teams are listed for your reference, and the user is removed from them during offboarding.

• Tools Access Visibility

  The list of tools the user has access to and the roles assigned to the user is available for quick reference.

• Offboarding Status

  You can check the offboarding status of a user once the process is complete. In the offboarding status, error messages are displayed if any issues occur while removing the user from a product or revoking their tool access.

  Offboarded users are tagged with the "Offboarded" label in the global list of platform users. When you retain a user in a product team but revoke their tools access, the user is tagged with the "Offboarded" label in the product team.

• User Removal from Common Team Across Products

  When a user is part of a common team across multiple products, removing the user from one product automatically removes them from other products associated with the same team.

• Java 21 Spring Boot 3.3 - Gradle

• Java 21 Spring Boot 3.3 - Maven

• Java 17 Spring Boot 3.3 - Gradle

• Java 17 Spring Boot 3.3 - Maven

• Java 21 with GraphQL Spring Boot 3.3 – Gradle

• Java 21 with GraphQL Spring Boot 3.3 – Maven

• Java 17 with GraphQL Spring Boot 3.3 - Gradle

• Java 17 with GraphQL Spring Boot 3.3 - Maven

• REST Assured 5.3

• Angular 18

• Node.js 22.x with TypeScript without Express

• Node.js 22.x without Express

• Node.js 22.x with Express

• Node.js 22 with Express API

• Django 5.1.1

• MySQL 8.4

To view all the supported tools and technologies, see Tools and Technologies Integrated with Lazsa Platform.

Deprecated Technologies

The following End-of-Life (EOL) versions of technologies are no longer supported in the Lazsa Platform:

• Angular 16

• Angular 15

• Java 21 Spring Boot 3.2 Gradle

• Java 21 Spring Boot 3.2 Maven

• Java 21 Spring Boot 3.1 Gradle

• Java 21 Spring Boot 3.1 Maven

• Java 21 with GraphQL Spring Boot 3.2 - Gradle

• Java 21 with GraphQL Spring Boot 3.2 – Maven

• Java 21 with GraphQL Spring Boot 3.1 – Gradle

• Java 21 with GraphQL Spring Boot 3.1 – Maven

• Java 17 Spring Boot 3.2 Gradle

• Java 17 Spring Boot 3.2 Maven

• Java 17 with GraphQL Spring Boot 3.2 - Gradle

• Java 17 with GraphQL Spring Boot 3.2 – Maven

• Java 17 Spring Boot 3.1 Gradle

• Java 17 Spring Boot 3.1 Maven

• Java 17 with GraphQL Spring Boot 3.1 - Gradle

• Java 17 with GraphQL Spring Boot 3.1 – Maven

• REST Assured 3.0

• Next.js 13

For information on how the Lazsa Platform handles technology deprecation and version updates, see Technology Version Updates: Recommendations and Guidance.

All changes to the Lazsa Orchestrator Agent configuration are now fully captured in audit logs. These logs provide a detailed summary, including the user who made the change, the date and time of the modification, and the previous and updated configuration values.

This audit history enhances transparency and accountability by providing a comprehensive record of configuration changes. This is useful for better tracking, troubleshooting, and compliance.