Enable ability to audit users by login methods.
When accessing "/users/$id" The response documents the following fields: _id [...] email [...] userName [...] firstName [...] lastName [...] roleId [...] active [...] groups [...] adgroups [...] activeDirectory [...] principalName [...] objectSid [...] uSNChanged [...] dn [...] preferences {...} uiSettings {...} created [...] lastLogin [...] lastUpdated [...] ldapDomainId [...] pendingExpiration [...] createdSso [...] I see 'createdSso', but that doesn't seem to indicate which users can log in via what method. When we're auditing users, we need to know which users have a password that bypasses SSO, These users are high risk, as without a way to audit them, we can't easily discover discover when users have a password configured that allows them to bypass organization SSO.
Update Connection Management API to allow the ability to automate updating Key's
Currently the connection management API allows a user to update connection information in an automated way. But when using KeyPair auth as Snowflake will be requiring very soon - we cannot use the same API to update the physical key. The current flow requires an admin to manually update a key by copy and pasting it into the file management. It is incredibly tedious and cumbersome for a user to have to update these one by one. I imagine more Sisense customers will realize this pain as the Snowflake timeline for KeyPair auth nears.
API to access a widget JAQL
There is already a prism method to do this (prism.debugging.GetJaql) but we would need a backend equivalent. We would need to fetch the JAQL associated with a table/pivot widget by providing dashboard id, widget id cube name (?) This is to enable us to invoke the /api/datasources/[cube name]/jaql/csv method.
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
REST API admin access on all endpoints
As admin, I can get other people's dashboards using the /dashboards/admin endpoint. However, the information returned is limited: I can't get a .dash file or widget objects. I want to use my admin rights on the /dashboards/{id}/export/dash endpoint to download every dashboard, even ones that haven't been shared with me. Perhaps this could be generalised to other endpoints that limit based on dashboard permissions or other permissions: If as admin I can grant myself access to an object through the UI, then I should be able to set a flag in my API calls to circumvent these restrictions.
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/21719
