scripts and plugins working with ComposeSDK
To ease the transition between dashboards embedded via iFrame and the ComposeSDK, widget scripts, dashboard scripts and (most important!) plugins/add-ons should also work with ComposeSDK, e.g. via a flag "allow_scripts_and_plugins" or similar. That way, when moving between the 2 embedding methods, there is less friction.Disabling navigation hover UI for viewer users in Sisense
What the Solution Does The RemoveNavigationHoverAndMenu plugin simplifies the Sisense navigation for viewer users by: Hiding the three-dots “more” menu in the left navigation. Hiding the dashboard metadata tooltip that appears on hover. Preventing hover-triggered UI behavior, so menus and tooltips do not activate. Leaving the default navigation fully intact for admins and authors. The plugin automatically detects the user’s base role (prism.user.baseRoleName) and applies these changes only for viewers. It uses scoped JavaScript and CSS to remove the unwanted hover interactions without modifying Sisense core files or affecting navigation performance. How it works: Viewer-only condition: Runs only for viewer users (where prism.user.baseRoleName === "consumer"). Hover interception: Capture-phase event listeners block hover tooltip appearance Scoped CSS: Injects a short style block to hide hover UI elements and remove tooltip styling. Installation: Download RemoveNavigationHoverAndMenu.zip. Extract the folder RemoveNavigationHoverAndMenu into your Sisense plugins directory:/opt/sisense/storage/plugins/Alternatively, upload it through Admin > System Management > File Management to the plugins folder. Refresh dashboards or restart Sisense to activate the plugin. Verification: Log in as a viewer user. Hover over dashboards or folders in the left navigation. Confirm the three-dots menu and metadata tooltip no longer appear. Log in as an admin and confirm the navigation behaves normally. Files included: RemoveNavigationHoverAndMenu/plugin.json RemoveNavigationHoverAndMenu/main.6.js RemoveNavigationHoverAndMenu/README.md Why It’s Useful Simplifying the Sisense interface for viewer users creates a cleaner, more focused environment that emphasizes content rather than controls. By removing hover-based menus and tooltips for viewers while preserving them for admins, this plugin improves usability without compromising functionality. This approach also supports governance and user-experience goals: Governance: Viewers no longer see or interact with features they do not need. Consistency: Admins and authors retain their full toolset for management tasks. Stability: The plugin modifies only the UI layer and requires no changes to data models or access permissions. With this small enhancement, organizations can deliver a more streamlined viewing experience while maintaining full control for those managing dashboards and content. Outcome After installation, viewer users experience a simplified left navigation that shows only essential content. The three-dots menu and dashboard metadata tooltip are removed, and hover-based interactions no longer trigger any UI overlays. Admins and authors retain the complete navigation behavior, ensuring full functionality for management and editing tasks. The result is a cleaner, more predictable interface for viewers and a consistent, role appropriate experience across the Sisense environment. Hover Before Change (for viewers): Hover After Plugin (for viewers): Three Dot Menu Before Change (for viewers): Three Dot After Plugin (Is not visible, for viewers): Side-by-Side Comparison Before and After Comparison:Ensuring Accurate PDF Export Headers When Programmatically Modifying Dashboard Filters in Sisense
When working with Sisense dashboards, programmatically modifying filters upon dashboard load via dashboard scripts for a specific user or circumstance is possible. However, an issue can sometimes occur when exporting these dashboards to PDF immediately after such modifications: the filter header displayed at the top of the exported PDF displaying the current dashboard filter state may not accurately reflect the current state of the dashboard filters. This article explains the cause of this issue and presents a solution to ensure that PDF exports display the correct filter information in the header.Week over week analysis with custom fiscal year: Use case of a fuel and convenience retail operator
Introduction Week-over-week (WoW) analysis is a key part of performance tracking for fast-moving, high-traffic businesses such as convenience stores, gas stations, and car washes. For these organizations, aligning the fiscal calendar with operational cycles rather than the standard calendar year makes reporting more meaningful. In this use case, the fiscal year begins on the closest Sunday to January 1st, ensuring each year starts with a full week. This structure simplifies weekly reporting and keeps week-to-week comparisons consistent across years, which is important for tracking trends like fuel sales, store traffic, and service volumes. While nonstandard, this setup is commonly used in practice. What the Solution Does For standard, fixed calendar or fiscal years, week-over-week analysis can be achieved using the “First Month of Fiscal Calendar” and “First Day of Week” settings, along with the PASTYEAR function. However, for dynamic fiscal years that begin on a weekday closest to January 1st, these features don’t provide a usable solution, since the start date can fall in the previous or following calendar year. The solution uses the Filtered Measure certified add-on and a custom dashboard script to handle the custom fiscal year. Two year filters are added to the dashboard: one represents the selected fiscal year (user-selectable), and the other represents the prior year for comparison (locked and optionally hidden), which is automatically set with a dashboard script. The Filtered Measure plugin applies the selected-year filter to the measure for the chosen period, while the prior-year filter applies to the measure for the corresponding period in the previous year. This approach ensures that week-over-week calculations respect the custom fiscal calendar, providing accurate comparisons across equivalent weeks. Note: In this particular implementation, the fiscal years and week numbers are pre-calculated in the database and stored as numeric columns. To create a Date dimension table in your Elasticube with fiscal years starting on the first Sunday closest to January 1st, refer to the SQL example below. Why It’s Useful This solution addresses the native functional limitation by respecting the custom fiscal calendar, ensuring weekly trends are comparable across years. As a result, teams can reliably track key metrics, such as fuel sales, store traffic, and service volumes, on a true week-by-week basis, supporting better operational planning and more informed decision-making. Attachments WeekoverWeekAnalysiswithCustomFiscalYear.dash.txt (dashboard) Sample ECommerce - Custom Fiscal Year.smodel.txt (elasticube) JS Script - Automatic Update for Second Year Filter.txt (dashboard script) SQL Query - Dim Date with Custom Fiscal Year.txt (custom table SQL query) For the script to hide the second filter, refer to this BINextLevel article: Hide dashboard filters. Note: remove the .txt extension before importing the dashboard (.dash) and the Elasticube (.smodel) files.
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
Sisense Add-On customBarColumnChart Disappearing Filters
We have an add on in Sisense named "customBarColumnChart", and when enabled, it then acts how the video is showing with the filter selection. When it is disabled, it acts normally. We use that add on in multiple dashboards, and want to know if there is a way around this, or if we need to edit each widget script to perform the custom chart sorting.
Add filter option in Report Manager UI to see errored reports
There is no way to filter the errored schedule reports on the Report Manager dashboard. We need to scroll through the pages to see the failures of the day. Is there any way you can add one more filter value, Failed, along with the following options (Running, Not Running, and Pending)?
Ability to add many items to add to widget at once
When adding a new piece of data to a widget, instead of having to add one at a time, add a checkbox to each item to the left of each item in the list. The user can check the box for each item they want to add to the widget, instead of having to add one at a time. This will speed up adding many items to a widget.
