Changelog

Learn about new developer features and improvements.

Link to RSS feed

For the Qlik Cloud feature changelog, visit What's new in Qlik Cloud.

Introducing classic/chart

classic/chart is a new UI for [qlik-embed](../embed/qlik-embed/why-qlik-embed/). classic/chart renders visualizations that have not been converted to nebula.js or use the classic extension api.

Using classic/chart

Like other UIs available through qlik-embed, when you want to use classic/chart in an embedded analytics context, set the ui property to classic/chart. If you use qlik-embed web-components it will look something like this:

<qlik-embed
    ui="classic/chart"
    app-id="<appId>"
    object-id="<objectId>"
></qlik-embed>

classic/chart compatibility

classic/chart will render supported visualizations from Qlik Sense applications. For a full support matrix, refer to the supported charts page.

Third-party extensions

Third-party extensions may not render properly within embedded contexts compared to the native Qlik Sense experience if the extension manipulates private code such as CSS. Manipulating CSS in the native experience is not supported by Qlik, therefore, it’s not supported in qlik-embed.

To learn more about third-party extension compatibility with qlik-embed, please contact the extension author.

Limitations

classic/chart does not support the following features:

  • Right-click context menu
  • Export data

You can learn more about qlik-embed on the Why qlik-embed page.

When you embed Qlik Cloud into your web applications, you likely require an authentication strategy that mitigates the blocking of third-party cookies by browsers.

Qlik is introducing support for OAuth impersonation tokens, which can be generated using a confidential OAuth machine-to-machine client for users in your Qlik Cloud tenant. Impersonation tokens are ideal for scenarios where:

  • The identity provider for your web application does not match the one configured for your Qlik Cloud tenant.
  • You wish to handle authentication on your backend.
  • You wish to avoid client-side redirects in the browser.

If you intend to implement a client-side (front-end) authentication strategy or if your web application does not have a back-end component, you should leverage OAuth SPA for your application.

Considerations if moving from JWT

This capability provides a comparable experience to using JWT to authenticate from a web application to Qlik Cloud, with the benefit of not being blocked by third-party cookie restrictions.

The key difference is that OAuth impersonation requires that users already exist in the tenant and uses pre-existing user group mappings, rather than supporting update of groups on the fly during token requests. This means that:

  • Users must exist in the tenant prior to requesting an impersonation token. You can accomplish this with qlik-api as part of the login flow.
  • You cannot update user-to-group mappings when requesting the impersonation token. If you wish to leverage groups for your security model, you should first impersonate a user login on the backend using JWT to associate the required groups with your user.

Learn more about OAuth impersonation

To discover more:

The admin.apps scope has additional permissions granting OAuth tokens with this scope applied non-interactive access to the personal and private resources end users in tenants can create and curate.

This update helps administrators address several management use cases involving resources in personal spaces and unpublished content in Qlik Sense applications.

Situations where this new ability is helpful include:

  • Access orphaned resources and content when users are removed from the tenant.
  • Change ownership from one user’s personal space to another.
  • Programmatically publish content in Qlik Sense applications located in shared or managed spaces.
  • Extract private content from Qlik Sense applications in managed spaces for app lifecycle management, such as promoting content to base-level.
  • Backup and version control resource metadata, such as Qlik Sense applications, automations, data pipeline definitions, and more.
  • Migrating resources and content from client-managed Qlik Sense to Qlik Cloud Analytics, or between Qlik Cloud tenants.

You can use this capability with qlik-cli, qlik-api, or calling tenant REST apis directly. This capability is not available in Qlik Cloud graphical user interfaces.

To learn more about how to configure and use this capability, please see the tutorial on managing personal and private content.

@qlik/api is a collection of javascript modules which each exposes an api built to make the integration process for javascript solutions as easy as possible. The library is built for both browser and NodeJS usage and will seamlessly integrate with qlik-embed libraries.

@qlik/api provides Qlik Cloud REST endpoints and access to the Qlik Analytics Engine (QIX).

REST

@qlik/api REST interfaces are generated from open-api specifications released from those Qlik Cloud services that exposes a restful API. The code generation tool runs using the specs, building typescript for all api calls documented in the specification. One module per api is generated.

You can learn more about the available modules in the REST section of the typescript types repository on Qlik Open Source.

QIX

Qlik’s Analytics Engine Service (QIX) is the runtime service for Qlik Sense applications and several analytics services in Qlik Cloud. @qlik/api offers a fully typed api for connecting to and consuming Qlik Sense Applications including “Qlik Sense mixins” which previously only was used internally by in-house Qlik developers.

More info about QIX can be found in the qix section.

Learn more about @qlik/api in the toolkits section.

This changelog provides 60 days’ deprecation notice of the Typescript version of the Platform SDK. The library is being replaced with the Qlik API.

The Qlik API offers the same capabilities and access to Qlik Cloud REST APIs and the Analytics engine, with the addition of officially supported Typescript types.

Switching from the Platform SDK to the Qlik API is straightforward, requiring only a few modifications to your code. The major change is in handling authentication when connecting to your Qlik Cloud tenant.

Authentication with @qlik/api:


//Backend applications
import { auth } from "@qlik/api";
auth.setDefaultHostConfig({
    authType: "oauth2",
    host: "<hostname>.<region>.qlikcloud.com",
    clientId: "<OAuth2_Client_ID>",
    clientSecret: "<OAuth2_Client_Secret>",    
  });

Authentication with Typescript Platform SDK:

const Qlik = require('@qlik/sdk').default;
const { AuthType } = require("@qlik/sdk");

const config =  {
  authType: AuthType.OAuth2,
  host: "<hostname>.<region>.qlikcloud.com",
  clientId: "<OAuth2_Client_ID>",
  clientSecret: "<OAuth2_Client_Secret>",
};

(async () => {
  const qlik = new Qlik(config);
  await qlik.auth.authorize();
})();

For more information about @qlik/api, refer to the release changelog for @qlik/api or visit the toolkit page at qlik-api.

Qlik is announcing a change in behavior for the Roles API. This API currently returns a list of all available roles on the tenant, and a change is being made to who can access this API.

As of April 9, 2024, only users assigned the Tenant Admin role will be able to access the roles API. All other users will be denied access with a http 403 error.

How to access role information for non-Tenant Admin users

Today, any user can retrieve role records as shown below. Once the change is made, any user without the TenantAdmin role will receive a http 403 forbidden response.

curl "https://<TENANT>/api/v1/roles" \
 -H "Authorization: Bearer <ACCESS_TOKEN>"
# Http 200 - Ok
{
    "data": [
        {
            "id": "<ROLE_ID>",
            "tenantId": "<TENANT_ID>",
            "name": "<ROLE_NAME>",
        },
        ...
    ],
    "links": {
        "self": {
          "href": "https://<TENANT>/api/v1/roles"
        }
    }
}

Although users without the Tenant Admin role will not be able to return all roles in the tenant, they remain able to list the roles that they are assigned either directly, or via group membership. They can do this via the /api/v1/users/me endpoint.

curl "https://<TENANT>/api/v1/users/me?fields=assignedGroups,assignedRoles" \
 -H "Authorization: Bearer <ACCESS_TOKEN>"
# Http 200 - Ok
{
  "id": "<USER_ID>",
  "assignedRoles": [
      {
        "id": "<ROLE_ID>",
        "name": "<ROLE_NAME>",
        "type": "default",
        "level": "user"
      },
      ...
  ],
  "assignedGroups": [
    {
      "id": "<GROUP_ID>",
      "name": "<GROUP_NAME>",
      "assignedRoles": [
        {
          "id": "<ROLE_ID>",
          "name": "<ROLE_NAME>",
          "type": "default",
          "level": "user"
        },
        ...
      ]
    },
    ...
  ],
  "links": {
      "self": {
        "href": "https://<TENANT>/api/v1/users/me?fields=assignedGroups,assignedRoles"
      }
  }
}

Qlik is announcing a 30-day deprecation window for an unpublished endpoint on the Groups API.

No sooner than 30 days from the date of this notice, GET /api/v1/groups/user-claims/:userID will be removed from the Groups API.

To migrate to a published endpoint, use GET /api/v1/users/:id.

curl "https://<TENANT>/api/v1/users/<USER_ID>?fields=groups" \
 -H "Authorization: Bearer <ACCESS_TOKEN>"
# Http 200 - Ok
{
  "id": "<USER_ID>",
  "groups": [
    "accounting",
    "developer"
  ]
}

This changelog provides 30 days’ notice of the deprecation and removal of two attributes in the POST /v1/sharing-tasks endpoint. This endpoint is used to create new sharing tasks. Other methods are not affected.

Previously, the attributes allowed you to provide a different name for an asset than the system name. With the upcoming changes, the service will no longer apply user-provided values, instead, it will use the system name of the asset.

The attributes are:

  • root>appName - the name of the source Qlik Sense application
  • root>excelData>name - the name of the report template used to generate output

No changes are needed to your code, as the API will continue to accept payloads with these attributes, but it will ignore any provided values.

Changes will be made no fewer than 30 days from the date of this notice.

For more information on Qlik’s API policies, please refer to the API policy page.

For more information on this API, please review the Sharing tasks API specification.

This changelog provides 60 days notice of deprecation and removal of the /v1/automations/settings endpoints.

These endpoints turn on and off Qlik Application Automation on a tenant, and this capability was superceeded by the addition in July 2023 of a new role, Automation Creator. This new role provides much greater flexibility in who can use automations, including at tenant, group, and user level.

For more information on Qlik’s API policies, please refer to the API policy page.

Migrating to use the automation creator role

To provide all users in the tenant with access to create and run automations, you must add the AutomationCreator role to the Everyone group.

Assuming the Everyone group already had the PrivateAnalyticsContentCreator role assigned, you would send a request to replace the assignedRoles with the new list of PrivateAnalyticsContentCreator and AutomationCreator:

curl -L -X PATCH "https://<TENANT>/api/v1/groups/000000000000000000000001" ^
-H "Authorization: Bearer <ACCESS_TOKEN>" ^
-H "Content-type: application/json" ^
-H "Accept: application/json" ^
-d "[{\"op\": \"replace\", \"path\": \"/assignedRoles\", \"value\": [{\"name\": \"PrivateAnalyticsContentCreator\"}, {\"name\": \"SharedSpaceCreator\"}]}]"

If successful, an empty response with an http 204 code is returned.

In a similar way, you can also assign access to groups from your Identity Provider, or to individual users.

For more information, please review the configure application automation topic.

Say hello to the new Example section on qlik.dev. This new section provides you with quick access to commonly used code snippets and scripts you can adapt and integrate into your projects.

Every example in this section will have a card providing a brief description and the language or tool you can use with it.

There are a lot of examples to share with you, and they’re being added to the gallery frequently, so make sure to subscribe to the changelog using the RSS link at the top of the page so you can stay up to date.

If you experience an issue with a snippet, please open an issue at the Qlik Cloud examples repository on Qlik’s open source Github. Include a link to the example, the problem, and if you have one, your proposed solution.

You can peruse the examples section here.

This changelog provides 60 days notice of deprecation and removal of some undocumented attributes from the response of the /v1/licenses/assignments endpoint.

Qlik is making changes to ensure removal of user names and other identifiable information from APIs where the data is available via other, more appropriate APIs.

For more information on Qlik’s API policies, please refer to the API policy page.

Deprecation of response attributes

The attributes name and userId will be removed from the response from the /v1/licenses/assignments endpoint. These are optional, undocumented attributes that can be set when assigning a license. It will still be possible to use these attributes in the API filter.

Note: The endpoint will continue to return the user’s subject as their primary identifier. Qlik recommends not using personally identifiable information (PII) in the subject attribute in Qlik Cloud. A good practice is to use system generated GUIDs to uniquely identify users.

When set on a license assignment, the response currently looks like:

{
    "subject": "QLIKBOT\\f0e92f326ac77427df155940fec39e6b",
    "type": "professional",
    "userId": "637390ec6541614d3a88d6c1",
    "name": "EU OAuth Client",
    "excess": false,
    "created": "2023-06-29T12:24:34.639Z"
}

After deprecation, the endpoint will return:

{
    "subject": "QLIKBOT\\f0e92f326ac77427df155940fec39e6b",
    "type": "professional",
    "excess": false,
    "created": "2023-06-29T12:24:34.639Z"
}

If you need to look up the userId and name, you can retrieve these using the list users endpoint.

curl --get --location 'https://<tenant>.<region>.qlikcloud.com/api/v1/users' ^
--header 'Authorization: Bearer <token>' ^
--header 'Content-type: application/json' ^
--header 'Accept: application/json' ^
--data-urlencode 'filter=subject eq "QLIKBOT\\f0e92f326ac77427df155940fec39e6b"'

This will return the full user information for the user with that subject, including the most current name and userId (returned as id) attributes.

{
   "data":[
      {
         "id":"637390ec6541614d3a88d6c2",
         "tenantId":"BL4tTJ4S7xrHTcq0zQxQrJ5qB1_Q6cSo",
         "clientId":"f0e92f326ac77427df155940fec39e6b",
         "status":"active",
         "subject":"qlikbot\\f0e92f326ac77427df155940fec39e6a",
         "name":"EU OAuth Client",
         ...

For more information on the license assignment endpoint, please review the v1/licenses/assignments specification.

OAuth 2.0 Authorization

OAuth is a standard security protocol for authorization and delegation. It allows third party applications to access API resources without disclosing the end-user credentials.

Qlik Cloud supports OAuth 2.0 Authorization Code and Client Credentials flows. The OAuth client can obtain an authorization code or send client credentials header to exchange it with an access token that can be used to access Qlik Cloud APIs.

Alongside this delivery you will also get OAuth support for tools and libraries.

Full tutorial OAuth single page applications with nebula.js can be found here

Beginning November 1, 2022, Qlik is enforcing rate limits to API requests on Qlik Cloud REST APIs. This means any API request originating to a REST API endpoint on Qlik Cloud is subject to rejection if the number of requests to an endpoint exceeds the allowed amount in a specified duration on that endpoint.

NOTE: Read on to learn more about how you may be impacted by API rate limits.

Learn more about API rate limiting at these resources:

Subscribe to receive update notifications

The qlik.dev changelog has an rss feed you can subscribe to by adding the URL https://qlik.dev/rss.xml to your preferred feed reader. Now updates from qlik.dev come to you in your inbox or wherever you consume syndicated content.

Are you looking for a way to consume the latest API updates in the Qlikosphere? Wondering what new tutorials have been added without having to visit every page on qlik.dev? Need to find out if you are using the most current version of qlik-cli? Or maybe you want to know what new APIs are available to you since the last time you visited?

The developer changelog on qlik.dev is the source for all of this and more!

Check out the blog to learn more.