Parameters Overhaul - UI/UX

[arikfr]

Parameters in Redash hold a lot of potential. We plan to completely overhaul the implementation both on the UI/UX front and also the backend implementation to allow more varied usage scenarios.

This issue is for discussion of the UI/UX improvement of parameters. There is also this board to track the actual progress.

The plan is:

• Refresh query when parameters update Refresh query when parameters update #2316
• Dashboard Parameters Dashboard Parameters #2641
• Explicit “Add Parameter” Button in Query Editor Explicit “Add Parameter” Button in Query Editor #2644
• Improve Date/DateTime type parameters Improve Date/DateTime type parameters #2642
• Date Range Type Parameter Date Range Type Parameter #2643
• Add Query Parameters and Snippets to the left area of the query editor Add Query Parameters and Snippets to the left area of the query editor #2645

We welcome you to share your thoughts and ideas.

[psydone]

2644 - I love being able to simply {{ my parameters in. A button is just more mouse movement which doesn't keep up with my brain.

2642 - 'improve' date time, I think the cal wheels are just a little buggy. I thought of hacking something myself around date/time params but then realised the dropdown allows you to specify 'humantime' variables that work equally well rather than selecting dates.... It would be neat if you could splice both 'humantime' handlers for high level dates and a date selector for getting granular.

I don't know if there's an ER or entry somewhere in GIT, I'm sure I saw it somewhere. The ultimate nice to have would be 'default values' for params. Dates in particular if null can make queries either invalid or needlessly ownerous on the datasources. 'Being able to specify a default date as '6 months ago' while allowing user reconfiguration and refresh would be an awesome nice to have.

[kocsmy]

@psydone we're going to keep the type-in way to enter parameters 👍

Thanks for the valuable feedback!

[psydone]

lol just as I received your message I saw the thread on github saying so... AWESOME!!

[thoechsmann]

My wishes

Multiselect parameters:

I would love to use parameters in queries like

SELECT *
FROM x
WHERE field IN ({{paramerter}})

This will not work currently when the parameter is a list of items. Like ('A', 'B').

Empty parameters:

Also I would like to be able to leave the parameter field empty. Currently query will not run in that case.

[adiracu]

What about parameters backed by a python function?

For instance, consider a simple country/appVersion filter. At the moment, I use the special keyword "all" that signifies all countries/app versions and use the CASE function in SQL:

CASE WHEN '{{country}}' = 'all' THEN True ELSE country LIKE '{{country}}' END
CASE WHEN '{{appVer}}' = 'all' THEN True ELSE appVer = '{{country}}' END

That works fine most of the time, but I'd also like to be able to filter all app versions between 1.10 and 1.12. If I write "1.10-1.12" in the parameter value, I'll have to write a pretty biggish SQL expression for interpreting this edge case.

While that's not a big problem by itself, if I have a dozen queries where I want this filter I'll have to copy paste this SQL expression.

Moreover, when using multiple such filters the initial SQL logic is obfuscated by these multiple CASE expressions all over the place.

If parameters could be backed by a python function, I could reuse this function in all queries, reduce the clutter in my original SQL and do more complicated processing in it (rather than SQL).

The SQL filters would be reduced to :

AND {{appVer}} where appVer could be either True or IN ('1.10','1.11','1.12'), values returned by the python function.

[arikfr]

I'm closing this one -- most of it is done and #2645 is a huge project on its own.