Allow changes to be pushed from Private to Shared viewing
This really should already be an option within this feature but the fact that is not is quite maddening. When I am working on my private dashboards, there needs to be a button to push changes from the private view to the shared view to then republish the results. This should already be a feature and know that many of our clients have complained about this feature. Please please make this update sooner rather than later.
Simply Ask modified NLQ model import-export within a *.dash file
Current behavior of the Simply Ask feature doesn't support automatic saving of the modified NLQ model to the "*.dash" file. So you loose your development work after exporting the dashboard with already enabled and tuned "Simply Ask" to a "*.dash" file. After importing this dashboard back to Sisense the feature is automatically disabled. Also if a developer will enable it manually it starts running based on the "By Default" NLQ model. This forces to redo all the work on the model back again which is time consuming and not efficient. We expect Sisense to consider in the future the development work on making this more convenient for a BI engineer. If a "Simply Ask" feature will be automatically enabled on an imported dashboard with a corrected model, it would be beneficial for dashboard deploy automation and will reduce unneeded additional manual work on setting up this feature again and again for different working environments for the same dashboard.
Different database connections on staging server vs production server
Hi, We have two cloud servers in Sisense: one for development (staging) and one for production. The staging server connects to our staging database. The production server connects to our production database. All cubes and dashboards are identical except for database connection strings and names. Our Git branching strategy follows these steps: Create a feature branch from staging. Make changes and push them to the feature branch. Open a pull request from the feature branch to staging. Test changes in staging. If approved, merge staging into master (production) to deploy changes. The Issue Git integration tracks database connection names, meaning both servers must either run on staging data or production data—this is not feasible for us. Proposed Solution We suggest implementing a decentralized environmental variable for storing database connections. For example: Use {database-server-name} as a placeholder in configurations. Set database-server-name = db_server_staging on staging. Set database-server-name = db_server_production on production. This would allow the same codebase to dynamically connect to the appropriate database without manual adjustments. Would love to hear your thoughts on this!
GIT Integration - Preserve Folders between environments
We use GIT Integration to promote our projects from our DEV environment to PROD. When we execute a Pull request in PROD, all the dashboards of the project are imported into the "ROOT" folder of PROD. Would it be possible to preserve the Folder structure of the dashboards as they were placed in the DEV environment
Keep the pod configuration defined after Sisense update
In our use case, we need to modify the configuration of certain pods such as exporting, external-plugins, and exporter-xlsx using the kubectl edit command. We have noticed that with each Sisense version upgrade, these changes are lost — meaning the configuration values revert to their default, pre-modification state. Would it be possible to retain these modifications after a Sisense version upgrade?
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'.
Quick way to update SSL certificate
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.Global ElastiCube Builds Schedule Report
Currently there’s no way on the Sisense UI to have an overview of when the next ElastiCube Builds are set for. Having such info available would make it possible to easily select relevant time slots to run load testing scripts for instance, but also more broadly to help understand and finetune the current Builds orchestration. In order to do so, we would like for admin roles to have access to a single table-like page that would list all the Builds scheduled in the next 24 hours with the following columns: ElastiCube name Build start date Build theoretical end date* Last successful Build duration * Build theoretical end date = Build start date + Last successful Build duration * (or NULL in the rare event where the Build has never succeeded before) Additional features: CSV Export Sort option on column headers Pagination Note: a single Elasticube can have more than one entry (in the example below, we assume the admin user opens the page at 3:00 PM and the ElastiCube_B's Build is launched every 2 hours).
Bld Pod Annotation
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."Customizable LivenessProbe and ReadinessProbe in Helm Chart
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).
