UX for dashboard sharing constraints


Dashboard sharing is not supported if any of its widgets include query parameters.
This has been stated in the help doc.

To avoid confusion I suggest:
• Disable the share button accordingly with tooltip explanation and link to help doc explanation.
• If dashboard already public, and is added with such a widget, a confirm dialog should appear when clicking “add to dashboard”: “Are you sure?” with an explanation, followed by an automatic unpublish.
This would have to be done for the two methods of adding widgets to dashboard 1) “Add Widget” in dashboard page 2) “Add to Dashboard” in Query page.



You’re correct here and we should’ve done this years ago along with similar flow for query embeds, as they have similar limitations. I was always postponing implementing this, as it seemed that support for parameters is around the corner… (it wasn’t)

@rauchy is currently working on reducing some of these limitations. #3383 is a step in this direction (although doesn’t affect shared dashboards yet).

Even with the work @rauchy is doing it will be gradual improvement:

  • Currently: no parameters are supported.
  • 1st step: only non textual parameters will be supported.
  • 2nd step: textual parameters with predefined values will be supported.
  • 3rd step: all parameters supported.

(besides the 1st step all other steps are assumptions and might change)

TL;DR I guess we should still invest the time in implementing what you outlined above, we just need to keep in mind it will change as the backend implementation changes.

Actually I think both methods should be combined. The “Add to Dashboard” dialog on query page should use the same dialog (and code) from the dashboard, just instead of picking a query you will pick a dashboard.


First PR https://github.com/getredash/redash/pull/3439



When adding a new widget, I was thinking of sth like this:
(when dashboard already shared and getting query result that has params)

  1. Selection disabled - same as for unpublished queries.
  2. Optional “Parameters” build-in tag - allows user to make a clear distinction.
  3. Button in corner with quick info. Click for full info in Help doc.

It’s simple to implement and communicates at the most relevant moment.

Wdyt @susodapop @arikfr ?


Two quick thoughts:

  1. Why not show a tooltip when hovering over the query explaining why it’s disabled?
  2. There is also the case of an existing query on a dashboard that gets parameters :open_mouth: But it’s probably less common.


show a tooltip when hovering over the query

You mean over the query title in the row instead of a corner icon?

an existing query on a dashboard that gets parameters

Good point. I’ll think on it.


Tooltips can be hugely distracting, though. I would much prefer a question mark icon that triggers the tooltip.