We have an embedded dashboard with multiple parameter-based controls for filtering the data. We use getParameters() to capture the current parameter values and are trying to use setParameters() to restore those values.
When a control has “Select all” selected, getParameters() returns Values: ["All"]
If we pass that back in with setParameters(), the result is not “Select all”, but a single item “All” is added to the control and it is the only value that is selected.
Changing the parameter’s default reserved value from SELECT_ALL to something else does not change this behavior.
Why doesn’t the SDK return the reserved value for “Select all”? (Default or custom)
Why doesn’t setParameters() accept the same values that are returned from getParameters() for “Select all”?
Hello @MikeB, this is a good question and honestly one of the more confusing aspects of handling parameter values in QuickSight. Something I would recommend trying to handle the value for select all would be to use ALL_VALUES. This should work for single or multi value string parameters. Now, if it isn’t a string the default value for select all is different.
Hello @DylanM. Thank you for the reply. We were thinking we would put in a work-around for now to convert the ["All"] returned from getParameters() to ["ALL_VALUES"] before calling setParameters(). It just seems odd that set doesn’t properly accept the values returned by get. We had a similar issue with null that required a work around until it was fixed…
Hello @MikeB, yeah NULL can cause some issue as well since the returned value for Select All when you are checking in a calculated field is NULL. I bet that caused some issues when handling NULLs from the APIs.
If you view a parameter from the QuickSight console and open the advanced settings dropdown, you will see the Recommended value for Select All:
If you hover over that i icon, you will see what QuickSight is actually using to handle Select All.
I’ll mark this as the solution, but please let me know if you have any remaining questions! I will also mark this as a feature request for our support team since it is a work-around solution. Thank you!
