To filter any data we need to add the filter on the right panel. Though this is possible only for a desinger and if a viewer wants to filter any other columns in the widget after the result set is displayed, they will need to download the table and filter in csv/excel. It will be really nice to be able to further filter the result set by viewer after the data is processed/displayed by having this option visible on every column header. Currently, clicking the column header only sorts the data, keeping a filter option on every column can allow the user to narrow down the results before downloading the file. Using this option, the viewers can filter any of their columns in table widget without having the need to download and analyze the results outside sisense. ... View more

While downloading a large csv/excel file (over several hundreds mb file) from the widget, there would be a long delay of couple minutes before the browser indicates the file has been downloaded. During this time, the user has no indication if the request to download is in process or has failed. It would be good to have an indicator to show the download of the file is in progress, so user would not click the download multiple times thus causing multiple queries to hit the backend.   ... View more

The page controls to change the pages are currently within the widget and its functionality is limited: Thus, if the number of rows to be displayed are increased to 50 or so, the widget window would get expanded and user will have to scroll to the bottom of the dashboard to see the page controls or change the widget page.  This can be avoided by placing the page controls at the bottom of the widget window and not limiting it to the size of rows. So the widget window size stays fixed and the user can scroll through the data within the table widget. This also helps view the dashboard in the page  without having the need to scroll down at the bottom of the dashboard. Additionally, also allow the viewer to increase the number of rows to be viewed in the widget. Example, a user should be able to increase the number of rows for a table widget to fixed numbers as 50 or 100. ... View more

It would be great if we were able to setup Active Directory for an individual tenant while having SSO enabled for another tenant. This would help us differentiate between our external customer facing and internal BI. ... View more

Add the ability to programmatically export a Widget with specific filters and/or to export it as a certain user using the /dashboard/{id}/widgets{id}/ endpoint. User Story#1 As an admin I want to make api calls to the widget pdf export endpoint and include userid and custom filters so that I can download an export on behalf of another user in the system and specify the filters  Acceptance Criteria I can pass 2 properties to the export endpoint: User Id and filters Both parameters are optional and can be used separately from each other If a user Id parameter is provided, the Widget is exported on behalf of the provided user including the current filters applied and data security rules. If a custom filters parameter is provided, the Widget is exported with the custom filters. There is no merge between the existing Widget filters and the custom filters parameter.  The is an option to provide an empty custom filters parameter, in this case, no filters are applied to the dashboard.  User story #2 As a user (not admin) I want to make api calls to the Widget pdf export endpoint and include custom filters so that I can download an export with custom filters  Acceptance Criteria I can pass a custom filters parameter to the export to the Export endpoint The custom filters parameter is a jaql query that will replace the current dashboard filters The custom filters will respect my data security  I can provide an empty custom filters parameter that will remove all filters from the report. ... View more

The number of source of frustration and confusion amongst our users, when building Dashboards, is conflicts/inconsistencies between Dashboard and Widget filters. I have separately suggested that Sisense introduce a visual indicator of widget-level filters and it sounds like that is planned for the future, which is great. Another related feature that a user suggested was a "reset all widget filters" button which would be a single place at the Dashboard level. If the user clicks it, it forces all Widget filters to (a) be deleted (or maybe disabled?), and (b) puts the widget filter settings back in-sync with the dashboard (meaning if the user has selectively toggled off Dashboard filter inheritance at the widget level, that will revert back to the defaults). This is a really quick and easy method to put users back to square one if they have painted themselves into a corner, so to speak. ... View more

Scenario: embedded Sisense By default, when creating a new widget, Sisense puts the user into the widget "Wizard Mode", which then requires the use to click "Advanced Configuration" to view the full-feature widget editor. We don't want our users to use "Wizard Mode" and to always be placed directly into "Advanced Configuration". This should be a configurable setting at the Admin level. ... View more

The in app Look and Feel UI theme editor is an improvement to the CSS editing of the past, but it has removed some capabilities that were possible in the past. Items that should be added to the theme editor Primary Button Outline color Cancel Button Outline color Primary button hover state text color Cancel button hover state text color ... View more

Currently you only provide a direct link to a dashboard.  Allow the ability to have the ID of the dashboard. That way customers embedding the dashboard into their main app can load it natively into their app instead of directing the user directly to the Sisense instance. ... View more

My team was adding scripts to widgets to add attributes to the embedded widget and noticed an opportunity to expand what metadata we can use in the scripts. Currently, we're using the widget description (`desc` field) to set a testid attribute, but by default that description is viewable in the embedded widget.  I'd love the ability for designers to add key/value pairs to the Widget class metadata that are accessible in the widget script. widget.on('domready', function(w) { const { oid, customMetadata } = w; // customMetadata is the new (optional) property on a Widget const testId = customMetadata['testId']; // a key/value pair added by designer const selectorString = `[widgetid='${oid}']`; const widgetElement = $(selectorString); widgetElement[0].setAttribute('testid', testId); });   ... View more

This scenario is for embedded Sisense. When creating a new widget from scratch, it seems like the new Widget wizard selects either an Indicator or Pivot Table type of widget depending on the nature of the data being selected by the user. More often that not, this is resulting in a Pivot Table being the automatically selected widget type. Often times, our users do not need to use Pivot Tables; and since Pivot Tables are computationally more expensive to generate, this results in us incurring unnecessary expense for compute on our data warehouse. I don't want to block Pivot Tables -- I just don't want them to be default widget type. I'd rather Sisense use Table as the default widget type; and/or allow Admins to define the default widget type. ... View more