Allow "packaging" of some tables inside of a dashboard or model

Hello,

This is a feature request to allow for this:

  1. Models and Dashboards begin to share some qualities of a Collection. That is, they can "hold" SQL-Queries and/or Questions.
  2. It would be nice if "held" SQL-Queries and/or Questions were scoped to the "holder". Meaning, the parent Models and Dashboards can reference the held Queries / Questions for which they are a parent of. However, attempt to reference from a Model / Dashboard that isn't holding the Queries / Questions should fail with an error.

Why: This pattern is already superficially implemented by users in many cases, though without support from the Metabase application to enforce the scope. Consider the following file structure in Metabase:

dashboards/
-|- dash_1/
-|-|- dash_1 *(dashboard)*
-|-|- dash_1_queries/
-|-|-|- table_1
-|-|-|- table_2
-|-|-|- ...

As seen above, the dashboard has some dashboard specific Questions / Queries.
This pattern naturally emerges because Models are often designed as a generally applicable dataset, meaning it gets used by many different dashboards. Therefore, there is reason to create a tailored version of a Model for each Dashboard its dataset should become part of.

The current solution is to do exactly that, create dashboard specific Questions and Queries. However, this solution is insufficient for a number of reasons:

  1. It does not limit scope of the "held" Questions and Queries, meaning search results are often muddled and difficult to look through. Consider that these Questions and Queries are often different versions of the same model, suggesting they may end up having similar names.
  2. It requires the user create their own organization scheme to handle this pattern. The result is often less scalable than if the application helped out.
  3. Any accepted organization scheme increase complexity of the file structure, as it's now muddled with directories that serve very little value globally. Consider: Users may only want to see "dashboard_queries/" for "dash_1" when that is explicitly what they want to see / troubleshoot. Not all the time whenever they are navigating Metabase.

One possible implementation would be to have a new "Private Collection" that gets associated with individual Models and/or Dashboards. Such as:

With the implementation being a "Private Collection" of sorts, it would allow users to easily move objects in and out of the collection. This sounds advantageous. Please let me know your thoughts.

thanks, what's the problem that you're trying to solve here?

Just clutter. Most of the clutter I experience comes from needing somewhere to put very narrowly focused charts and tables. These charts and tables might be built for a single dashboard, and so they don't need to be seen so easily. It would be nice to be able to tuck things away somewhere where they are out of sight and out of mind- from general search results included.

But it would also be nice to not have to stick them all in the same place, like some generic "Dashboard Queries" collection.

Right now, I keep a collection next to every dashboard. For example, a dashboard named "Apples"

/
| - Apples
| - queries - Apples/
| - | - apples_query_1
| - | - ...

The problem comes with scale. Once you have 50-100 dashboards, each needing its own unique subqueries, and many of those needing their own subqueries, it becomes a bit of an eye sore.

Then when you're wanting to add queries to a dashboard, and using the search function to find it from within the edit dashboard screen, you must search through hundreds of irrelevant queries. 90% of the queries are only relevant to a single dashboard.

So, I guess I'm just trying to consider ways that the platform could help users de-clutter.