Native Support for Salesforce Connected App Authentication
Salesforce has announced that API Access Control must be enforced, and once fully enforced, the username/password + security token method will no longer be permitted for API integrations. https://help.salesforce.com/s/articleView?id=005228838&type=1 While the current Sisense guidance allows us to continue using token-based authentication, we belive this is only a temporary gap in Salesforce’s enforcement. We expect that Salesforce will require all integrations to authenticate exclusively through an allowlisted Connected App using OAuth. This is not a feature request in the traditional sense. It is a compliance requirement dictated by Salesforce’s security model, and other analytics and reporting tools that integrate with Salesforce already support Connected App–based OAuth authentication natively. To ensure long term compatibility and security, Sisense needs to provide: Native support for OAuth via Salesforce Connected App, without requiring manual JDBC string assembly or custom development A UI-driven configuration aligned with Salesforce’s allowlisting and API Access Control policies Clear guidance for customers migrating away from token-based authentication Without this capability, Sisense will no longer be able to integrate with Salesforce once Salesforce completes enforcement. Please escalate this as a priority compliance feature.
Enable ability to audit users by login methods.
When accessing "/users/$id" The response documents the following fields: _id [...] email [...] userName [...] firstName [...] lastName [...] roleId [...] active [...] groups [...] adgroups [...] activeDirectory [...] principalName [...] objectSid [...] uSNChanged [...] dn [...] preferences {...} uiSettings {...} created [...] lastLogin [...] lastUpdated [...] ldapDomainId [...] pendingExpiration [...] createdSso [...] I see 'createdSso', but that doesn't seem to indicate which users can log in via what method. When we're auditing users, we need to know which users have a password that bypasses SSO, These users are high risk, as without a way to audit them, we can't easily discover discover when users have a password configured that allows them to bypass organization SSO.Enable end-to-end tracing visibility for Sisense services to complement existing metric monitoring.
Description: We are looking to send Sisense application traces to SignalFx (Splunk Observability Cloud) and would like guidance on leveraging the OpenTelemetry framework to achieve this integration. Currently, OpenTelemetry is not configured in our environment. We would like to understand: Whether Sisense supports OpenTelemetry out of the box for traces, The required steps to enable and configure OpenTelemetry in a Sisense deployment (Linux EC2, single-node, Kubernetes-based), How to route traces from Sisense to SignalFx, including configuration files, environment variables, and any required Sisense plugins or modules, Any limitations or known issues with trace capture for Sisense microservices, Example configuration snippets or reference documentation for this setup.
WAT and ACL Security Model - Default to no access
We have found that if an ACL in a WAT does not match the Elasticube table/column security field, it defaults to providing 'all data'. To avoid a potential human error where a table/column has been renamed, we would like the default position to be 'nothing'.
Data Security Search Limit Max
The Data Security tab's group/user assignment window currently has a max search limit of 20 results. The "results" search limit should be configurable because we have approx. 50 groups that need to be assigned, & it is very difficult to find/assign/manage all of the groups when the search window does not return all of the appropriate results.
Local Development Environment
Idea: Allow developers to build/test add-ons in a local environment rather than requiring a live environment. Note that this would be for the purpose of creating custom add-ons for additional functionality that would require testing on the "out of the box" Sisense UI. Background/Context: In most development workflows it is common practice to work on your code locally on your machine and deploy to a local server aka "localhost" to test/view your work in the browser. An example of this is building and deploying a local React.js app to your browser. As you make changes to the code it will recompile locally and update what you see on your localhost. If you're using Sisense out of the box however, to test/view any changes to an add-on developers are forced to upload the files in some way to a live Sisense Environment. This not only limits the innovation of add-ons to developers with an active license and live environment, it makes it painfully inefficient to develop customizations on top of the Sisense application. I understand there are likely some business concerns with allowing the use of the product locally but I'd argue that there are ways to prevent that, such as enforcing some default sample data etc., but in such a way that would give developers a "local playground" to develop/innovate on.
