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'.  ... View more

It would be interesting to be able to modify livenessProbe and readinessProbe values in Sisense Provisioner's Helm charts (chart.png).   Currently, the values are hardcoded in the deployment charts. It is therefore not possible for us to change the values using a value file (configuration.png). ... View more

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. ... View more

The helm chart supplied with Sisense allows global annotation of all service accounts within the sisense namespace. For example I can annotate an AWS role that is able to be assumed by pods: helm upgrade sisense ${sisense_chart} --namespace sisense \ --reuse-values \ --set global.serviceAccountAnnotations."eks\.amazonaws\.com/role-arn"=${pod_role_arn} While this covers most of the pods by updating all the sisense-* service accounts in kubernetes the ec-build pod (the one that actually builds the elasticube) only uses the default service account in the sisense namespace. A workaround is to annotate the default service account: kubectl annotate serviceaccount default eks.amazonaws.com/role-arn=${pod_role_arn} --namespace sisense But it seems odd that the pod would a) assume the default service account when all other pods have service accounts explicitly defined for them and b) despite having gone to the trouble of wiring up global service account annotations in helm for them not to be applied at the final step of elasticube building. This specific use case is for supplying web identity tokens to a JDBC driver so that you can interact with AWS by using a specific OIDC assumed pod role, rather than using an EC2 role or worse, static credentials in a file or connection string. Even more specifically using CData JDBC parquet driver with S3.   ... View more

It would have been great if there was a quicker way to update the SSL certificates on the Sisense server without having to run the update install. There are clients who do not wish to provide internet connection on the server once Sisense install is complete. As I understand it, if Sisense was installed with internet connection on, then we need to have internet connection in order to re-run the installer successfully. So we will have to make a request to the client to provide internet connection again to run the update install. It would have been good if there was an alternative way to update the SSL certificate.  ... View more

As of L2023.3, in Sisense’s Helm Charts , “Tolerations” are supported by the micro-services. It prevents end-users from configuring “Taints” on the node that they want to dedicate to Sisense. Since no “Taints” are configured, so all nodes can become eligible to host Sisenses’s pods. They experienced that scenario when pods from some other application services were scheduled on a Sisense node. Would you please consider allowing the pods to be protected not only with  “Toleration” but also with “Taints”. The justification for this is that, even though it is mentioned in prerequisites documents that Sisense should be installed on dedicated servers, there is a non-negligible factor from the customers perspective that is the overhead administrative costs, especially for customers who must already manage numerous clusters for several applications, multiple environments, and redundancy.   ... View more

I have a client that has SSO users and non-SSO users.  On Sisense advice, we have created a separate tenant for the non-SSO users.  We expect that those users would have all user email features of users as if SSO did not exist on the system.  We are finding that the new user invitation email is not enabled for these users (among other email functions).  Therefore, these users are not able to set their passwords when they are created.   As a result, we are using a common password for 600+ users.  This is obviously not satisfactory.  Those tenant users can now log in and change their password, but we have no way to enforce that they do this as we would with an invitation email.   R&D has told us this is the expected behavior (refer to case #00746676).  This behavior is not working well for my client.  I would like all user email features enabled for non-SSO tenants. ... View more

We'd like to be able to annotate our bld pods using the helm provisioner. Annotation we're wanting to apply: karpenter.sh/do-not-disrupt: "true" Per Sisense support:  "If we are discussing the -bld- pods, it’s important to note that their configuration cannot be overridden manually. These pods are dynamically generated by the Management service, and the logic for their creation and configuration is embedded within the Management service code. As such, direct modifications to their configuration are not supported." ... View more

Please enable the possibility of selecting a default CSI (storage class interface)  from a set of existing CSIs so that it may be used as default Sisense persistent storage option. This is is a necessary feature for persistence of storage in cases such as autonomous cluster scaling or rebalancing, as well as disaster recovery.   ... View more

Some end-users have several environments where they must provision Sisense and they strive to standardize and automate the processes as much as possible for efficiency. It would be great to be able to extend standardization and potential automation of configuration to the Helm Chart level: Please include some ways to enable feature or disable feature with the helm chart so that if we want to enable file management everywhere we could provide a value to all our helm charts so we can have uniform configuration. ... View more