Qlik is removing the com.qlik.user-identity.impersonation event from the audits service
in Qlik Cloud. Events of this type will no longer appear in the Events panel in your
tenant’s management console and responses from the audits API will no longer include
this event.
This change is a result of analysis which found the event added little customer
value, with a better solution being to add the actor attribute to service events to
indicate when a user was impersonated. This reduces audit complexity for customers,
as well as the volume of events a customer needs to process to determine the actions
their users are generating in the platform.
Note: The com.qlik.user-identity.impersonation is not deprecated, it is simply
being removed from a service that aggregates and surfaces events for external
consumption.
This change will take effect no sooner than sixty days from the date on this changelog entry.
qlik-embed web components script src attribute changes
A change to the latest release of qlik-embed web components requires references
to the index.min.js file be specified for the library to run.
If you are using qlik-embed web components it is recommended you update the src
property of the script element declaring the full path to the library.
Update the attribute to include /dist/index.min.js in the path. Here is an example of
the new path for the src attribute:
src="https://cdn.jsdelivr.net/npm/@qlik/embed-web-components@1/dist/index.min.js".
Note: If you do not want to use the latest version of qlik-embed web components, it is
possible to set the version in the path.
Here is an example of the src attribute referencing a pinned version of qlik-embed
web components:
src="https://cdn.jsdelivr.net/npm/@qlik/embed-web-components@1.1.1/dist/index.min.js".
Update the oauth-callback page used to handle connectivity between qlik-embed web components
and your Qlik Cloud tenant. Set the src attribute to use oauth-callback.min.js.
The resulting src attribute should look something like this:
src="https://cdn.jsdelivr.net/npm/@qlik/embed-web-components@1/dist/oauth-callback.min.js".
You can learn more about qlik-embed
on the Why qlik-embed page.
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:
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.
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:
Review the guiding principles
for using OAuth impersonation in Qlik Cloud.
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.
@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.
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.
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.
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.
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:
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.
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:
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.
Full tutorial OAuth single page applications with nebula.js can be found here
Capability APIs?
Already have a Client Id? just switch the webIntegrationId config with the clientId instead,
that’s it. See example code in the
Build a simple mashup using capability APIs
tutorial.
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:
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!