L2022.4 Release Notes

For a list of release dates and Sisense's end of support schedule, see Sisense Life Cycle.

Release Overview

Release L2022.4 provides a number of new features and significant improvements to Sisense for Linux.

What's New

This release includes the following new features:

• New Sisense Filters

• OIDC SSO acr_values for Embed SDK/IFrame Support

• Web Access Token - Data Security Per Data Source

• Web Access Token - Public Endpoint 'Create WAT'

New Sisense Filters

• Sisense introduces new filters that provide additional filtering capabilities, as well as a more streamlined and flexible filtering experience.
• The new filters feature is OFF by default. To try the new interface, an Admin must first enable it via the base configuration (under "FiltersModal"). Any active filter sets that you currently have in your dashboards remain active in the new filters interface. Note:: Before enabling, take note that any add-ons that rely on the current filters interface may stop working.

See Creating and Editing Filters.

OIDC SSO acr_values for Embed SDK/IFrame Support

• Sisense introduces support for 'acr_values' for OpenID Connect (OIDC) SSO protocol.
• This protocol is compatible with all types of embedding and can be passed via the 'ssoparams' embedding solution constructor parameter.
• 'acr_values' are used to specify the Authentication Context Class Values within the Authentication Request.
• The parameter should be provided in base64 encoding format.
• For example: https://example.com/js/sisense.js?ssoparams={params in base64}

Web Access Token - Data Security Per Data Source

• We have enhanced utilizing data security in the Web Access Token environment, by enabling you to apply data security rules per data source.
• To correctly apply data security include the new "dataSourceTitle" parameter (containing the title of the queried data source) to each "acl" claim object.
• With this new improvement the "dataSourceId" parameter is deprecated and should be excluded from the payload. See "acl"The Web Access Token enables applying data security rules for each token, and in doing so, dynamically defining the scope of available data for the end analytical consumer, on a per business case basis."grants": { "acl": [ {acl1}, {acl2}, etc ] }The overall approach of processing "acl" is similar to other available claims:"acl" is not specified or outside of the "grants": { } claim → inherits as-is data security from the native Sisense system, if any exist and were applied to the user from "sub"."acl": [ ] → erases all existing data security rules applied to a "sub" user in the native Sisense system. In such cases there is no data security whatsoever applied."acl": [ {acl1}, {acl2}, etc ] → overrides any existing data security applied to a "sub" user in native Sisense to those received from the token.Structure and format a token's data security as follows:Copy"grants": { "acl": [  {   "dataSourceTitle": "Sample ECommerce",   "table": "Commerce",   "column": "Gender",   "allMembers": null,   "datatype": "text",   "members": [    "Male"   ],   "exclusionary": false  } ]}To correctly apply data security, you must include the new "dataSourceTitle" parameter (containing the title of the queried data source) to each "acl" claim object.Note:The data security rule is ignored if no widgets are based on the same data source as specified in "dataSourceTitle". Data security, as well as other claims in a Web Access Token flow do not work in 'addition' mode. Settings are either inherited from the native Sisense or replaced with the settings from the "acl" claim, as long as the claim is included in the payload. Therefore, the data security rule is ignored if no widgets are based on the same data source as specified in "dataSourceTitle".Example:A dashboard is based on four different data sources; A, B, C and D, each of which has data security configured in native Sisense.Passing "acl": [{"dataSourceTitle": "A", ....}] applies data security in the Web Access Token environment to any widget based only on data source A. The widgets based on data sources B, C and D have no data security applied or inherited from native Sisense.Therefore, make sure to specify data security per data source, if such is required in your business case. Alternatively, if you want native Sisense data security to be inherited, do not include the "acl" claim.

Example:

"grants": {
 "acl": [
  {
   "dataSourceTitle": "Sample ECommerce",
   "table": "Commerce",
   "column": "Gender",
   "allMembers": null,
   "datatype": "text",
   "members": [
    "Male"
   ],
   "exclusionary": false
  },
  {
   "dataSourceTitle": "Sample Lead Generation",
   "table": "Lead Generation",
   "column": "Country",
   "allMembers": null,
   "datatype": "text",
   "members": [
    "United States"
   ],
   "exclusionary": true 
  }
 ]
}

Web Access Token - Public Endpoint 'Create WAT'

• Sisense introduces the capability of generating Web Access Tokens directly from within the application.
• Ability to generate Web Access Tokens directly from Sisense can assist users lacking their own developed token generation tool, or simply for generating tokens outside of a programmatic flow.
• Structure and logic validations are executed towards the token's header and payload, with descriptive human-readable error messages.
• Previously-created secrets should be regenerated as strings (without break-lines) to pass API requirements.

Example:

What's Improved

Helm 3.8.1 Supported

• Sisense now supports Helm version 3.8.1 The new Helm version can be used in addition to older versions.

Kubernetes 1.22 Supported

• Kubernetes 1.22 is only supported for RKE or Provisioner installations. See Upgrading Sisense on Linux.

What's Fixed

BloX

• Fixed UI displaying escaped special characters
• Fixed editing BloX custom actions

Embedded Mode

• Fixed displacement of filters panel on iPad.

Security

• This release contains several security related updates, including bug and vulnerability fixes. We highly recommend upgrading to this latest release to take advantage of any security-related updates and benefit from the Sisense support and warranty.

Web Access Token

• The format of the generated secret (public key) was changed to string, without line breaks, in order to meet the Web Access Token - Public Endpoint 'Create WAT' API validation requirements. Previously generated secrets should be regenerated if you wish to use Sisense Implementation when creating new tokens.
• The ability to utilize pivot widgets in the Web Access Token based Sisense.js environment has been fixed.

Video

Watch this video for an overview of selected features from this release: