This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Cookie Policy. Click Preferences to customize your cookie settings.
Mastering custom actions in Sisense: debugging and understanding payload properties
When you use a custom action from the community, develop your own, or try to understand why your action does not work as expected, sometimes you need to change the custom action’s logic. Maintaining someone’s code or developing your code is not easy when the code is executed in a 3rd party environment (Sisense). In this article, I will explain what properties are passed to the action and how to debug custom actions.
When you need to understand what goes wrong, use a magic word debugger. When the browser’s developer tool is open, the code’s execution will be stopped on this code’s line.
Let’s create a simple action with a single line of the code:
debugger
As the action’s snippet use the following one:
{
"type": "testAction",
"title": "Test action",
"data": {
"firstArgument": "string",
"secondArgument": "boolean"
}
}
Use this snippet as an action. As a result, you will see a new button on your widget. Open the developer tool of your browser and click on this button.
The code’s execution was stopped on the line debugger and you will see the following code:
(function anonymous(payload) {
debugger;
})
If you hover over the variable payload, you will see its value. Using this argument, you can get access to other parts of the currently opened dashboard. For example, the dashboard’s filters are located in the following path:
payload.widget.dashboard.filters
Also, you can get other widgets from the dashboard, using the following construction:
payload.widget.dashboard.widgets.get(widgetId)
In this logic, the variable widgetId is the identifier of the widget you want to get from the current dashboard.
Word debugger can be added to almost any line of your action, so you can debug your logic.
If the code’s execution was not stopped in the debugger, there can be the following reasons:
- Some issues occurred earlier in the custom action, so you need to place the debugger earlier;
- The custom action was not called, because it does not exist. In this case, you will see the following message in the console:
BloX Alert!
The action type was not found.
- Breakpoints are deactivated:
[ALT text: Screenshot of a debugging interface showing a toolbar at the top with various icons. An arrow points to the "Deactivate breakpoints" icon, accompanied by a tooltip that indicates the keyboard shortcut (Command + F8) for the action. Below, there are sections labeled "Breakpoints," "Scope," and "Call Stack," with options and statuses displayed.]
- Conclusion: A summary of key takeaways or final points.
Using this approach you can easily develop your actions.
- References/Related Content: Links and resources for further reading.
https://docs.sisense.com/main/SisenseLinux/creating-custom-actions.htm
https://sisense.dev/guides/customJs/jsApiRef/widgetClass
https://sisense.dev/guides/customJs/jsApiRef/dashboardClass
DO NOT CHANGE!!! Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.
