Bug: Refresh schema all tables
In my data model, I clicked "Refresh Tables Schemas" to refresh for all tables in my data model. It incorrectly told me that one table could not be found in source (I then did Refresh Schema on that same table individually and it worked). Probably related: A colleague tells me that in their experience Refresh Tables Schemas is unreliable and as a result they refresh tables individually, but haven't given me exact steps to recreate the issue. I think it sometimes misses schema changes.Improve Build Notifications by Classifying User-Cancelled vs Failed Builds
I suggest enhancing our Sisense build notification process by automatically classifying emails as either “Cancelled by User” or “Build Failure.” This distinction will help us quickly identify which build interruptions were intentional versus actual system issues, improving response time and reducing unnecessary troubleshooting.Refresh schema for all tables
Can we get a "refresh schema for all tables" button? Reason: Our tables are usually "Select * From AnalyticsSchema.ViewName". We control which fields to return by editing the view, not the Sisense table definition. When a field gets added/removed/changed, we need to refresh schema. That's fine to do manually as you're working on that datamodel+views, but we need to refresh all when: We copy a datamodel to a different server. We need to refresh schema at least to double-check that the views are as expected on the new server. (If any fields have changed, then I'll need to go fix any widgets using those fields, or, more likely, update the view to include them.) A view gets edited, perhaps for a different datamodel, and my datamodel hasn't been updated. I edit several views and want to refresh schema for all those Sisense tables. If I've changed used fields then I'll need to go into each table manually anyway so it doesn't matter, but I've had a case where I've removed unused fields from several views and now I need to click refresh schema on every table individually.
The row count should remain when using order by in the query builder
Currently when you run a Select statement the number of rows and columns are shown at the top of the result set. However, when I add an order by clause to the query the row count is removed but the column count remains. Can the "# Rows" value remain once an order by clause is added?
Request for API to Programmatically Retrieve Widget-Level Error Responses in Sisense Dashboards
We are currently conducting automated tests on Sisense dashboards to ensure data reliability and visualization integrity. To detect failures, we’ve been using HTML tags to inspect widget responses. However, this approach has limitations especially with indicator widgets that use the <canvas> tag, which restricts DOM-level access and makes it difficult to capture error states. We’ve also explored using the POST /datasources/{cubeName}/jaql API to fetch data, but the payload is large and complex, making it challenging to parse programmatically for error detection. Given these constraints, we’re looking for an API or method that allows us to programmatically retrieve widget-level error responses or statuses from the dashboard. This would significantly improve the reliability and coverage of our automated testing framework Feature Request: Introduce an API or system-level mechanism to: Detect and retrieve widget-level error states Identify query execution failures tied to specific widgets Support automated testing and validation workflows
Add functionality for updating the Elasticube a Pulse Alert is associated with
When changing the Elasticube associated with a dashboard, any Pulse alerts built off widgets from that dashboard will not be changed and will continue to be affected by the old Elasticube. This is an issue if you are replacing one Elasticube with another. There is no warning / message when changing a dashboard's Elasticube that pulses will be affected. There is no way to see the Elasticube a pulse is attached to - only the dashboard (but again, changing the dashboard's Elasticube doesn't change the pulses). There is no way to see which pulses are built on top of an Elasticube from the Elasticube screen (unlike with dashboards). I would like the ability when changing the Elasticube for a Dashboard that has Pulse alerts associated to it, give the prompt option to update to the new Elasticube for Pulses as well. This could either be done: Via some new UI Via some warning (similar to when you try and delete a cube with active dashboards / pulses) - but this would then also need the secondary ability to manually change the Elasticube associated with Pulses.
Give developers the ability to explore production without being able to modify
right now we can only allow our developers to either edit models in test or read/use. With read/use they aren't able to actually see the cube in the data page. I need my developers to be able to explore connections, schemas and tables in prod without having the ability to actually make any changes. https://community.sisense.com/category/support/discussions/supportportal#case-detail:500Pk00000mKN4vIAGCreate New Sample Data Sets with more data and more concurrent date ranges
Create a new sample data sets that have a lot more data, date ranges that are current to our dates today, has more scenarios that we see in all customers cases. Like more complex formula creations, displaying a wide range of different KPI's, have a more complex data model to show how dimensions and fact tables can work. Having a sample data set with custom code, custom tables, and custom column. Having one of the tables connect to a DW to show how the connection works as well.
SingleStore (MemSQL) Connector: Use CONCAT instead of Pipe operator (||)
The queries Sisense generates in some cases uses the pipe operator (||) to concatenate the strings. However, SingleStore has 2 different modes of treating the pipe operator, depending on @@sql_mode engine variable and PIPES_AS_CONCAT flag: flag is ON: pipe operator is treated as CONCAT and the Sisense-generated query works flag is OFF (default): pipe operator is treated as OR and the Sisense-generated query throws an error In order to avoid the ambiguity, I suggest that SingleStore (MemSQL) Connector uses CONCAT instead of pipe operator by default.
