Enhance Widget Export API
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.
API to retrieve Sessions Table details
**Please note this idea was migrated to the Product Feedback Forum from older submission areas** Sisense doesn’t have an API to get data from the Sessions Table. This data is available in the UI only. We would like to be able to use this data in a custom application that we have built. We’d like to see an API that will allow us to get the Session Table details.
Local Development Environment
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.Refresh Schema via API
We are trying to investigate how we can trigger a Sisense data model (schema) refresh from the API. This call would be made after a data pipeline schema change. We’ll need the calls to make to "Refresh Schema" how it is done in the UI. Original Community Post by haarishussain : https://community.sisense.com/t5/help-and-how-to/sisense-api-model-refresh/td-p/21719MongoDB driver-version compatibility
Some of our customers are being forced to upgrade Mongo, and we need to upgrade our drivers in order to match. On 2023.7 we are using driver version 1.3.11 which is not compatible with MongoDB 4.2+ and our customers mentioned they are being forced to go to MongoDB version 5 or 6.A new endpoint to get all pulse alerts through the API
It would be nice to have an officially supported Events endpoint, that lists all the alerts / pulses / notifications that were sent out when an event was triggered. This allows users to create dashboards giving a quick overview of where problems occur. There already is an /events endpoint, but it is not officially supported and not listed in the APIs, so we were only able to find out about it by creating a support ticket.
