1

In #2721 it was suggested to display more informative and user friendly feedback when query results fail due to missing parameter value.

But parameter validation can be made even broader as there are other validations being done in the backend which can emit dedicated significant feedback.

In #4264 I attempt to adhere to all validation cases and here they are up for discussion.

1. Missing value

When a parameter has no value.

26
261112×366 15.2 KB

2. Invalid value

Numbers for Number params, string for Text params, object for DateRange params etc.

In the following screenshot, a valid DateRange param was changed to a Text param which doesn’t accept an object as a value.

11
111112×366 17.4 KB

3. Missing parameter

When a widget executes a query which has since been added a new parameter.

30
301158×600 27 KB

4. Redundant parameter

When a widget executes a query with a parameter that has already been removed.

26
261158×502 34.9 KB

5. Mismatched parameter

When there’s a mismatch between the parameter type and the expected template tag in the query text.

When a DateRange param is missing {{ param.start }} or {{ param.end }}.

19
191102×354 19.3 KB

Same for the opposite case, when a non-DateRange param is missing the normal {{ param }}.

34
341102×338 22.4 KB

But if the same mismatch happens when the query is not saved - meaning, no schema to validate by parameter type - a more generic error is shown, suggesting to save the query and rerun.

33
331102×374 24.9 KB

6. Unsafe parameter

When there’s an unsafe parameter in a widget of a limited access public dashboard.

33
331158×600 33.6 KB

7. Unsaved parameter

This one is not really related but I felt the parameter feedback mechanism could be used to show this as well.

When a new parameter has been added but query not yet saved.

38
381112×216 9.38 KB

Lmk what you think.

3 Likes
2

Excellent usability improvement. I was just lamenting the lack of this sort of contextual errors on parameters last night. I feel like building Redash into our project is strapping us to a rocket engine. Keep it up!

5 Likes
3

I’m not sure we need to change the current behavior. Because the user can’t do anything about it, it’s enough just to show the message.

When showing this it’s unclear for the user what to do. Maybe show a hover message saying “Click on Save”?

Are you sure this generates an error?

  • Should be Required Parameter.
  • I wonder if just a simple asterisk is enough and show the full message on hover? It just that some of those messages are long.
4

Thanks, @chrismerck :pray: Appreciate the feedback.

5

I’m not sure we need to change the current behavior. Because the user can’t do anything about it, it’s enough just to show the message.

It’s mostly valuable for unsafe dashboard parameters, in which it is harder to correlate between a failing widget and its actual unsafe parameter.
That said, it’s not a must so I’ll remove the implementation.

Maybe show a hover message saying “Click on Save”?

:+1:

Are you sure this generates an error?

Yes. Due to this param check:

But since having a redundant parameter won’t fail the query, it can be ignored - how about removing this check altogether?

Should be Required Parameter

:+1:

I wonder if just a simple asterisk is enough and show the full message on hover? It just that some of those messages are long.

I’ll give it a try.

6

This check is needed, but what we can do is remove any parameter value that doesn’t have a matching parameter. There is no harm in ignoring them this way. @rauchy what do you think?