We have the same situation that Thomas and Brian. This feature it is really valuable for us. We have to duplicate the charts the number of different databases for customers we have. And as Brian said, we have to replicate to all the charts if we do any change. If the database could be selected dinamically using the same structure, it will be awesome. Another possible solution between this is to define a database for a dashboard.

we operate our products in a multi-instance environment and we follow strict development lifecycle with dev, qa, UAT, production and DR i.e. we have hundreds of charts in our dashboard. synchronizing changes manually (across tenants / instances) is not scalable, but also very error prone, so resolving this issue is fundamental for us. we like the dynamic data source capabilities. that would solve the issue. another way could be the concept of master chart and chart instances that has a relationship to the master chart. whenever the master chart changes, all of it's instances change as well. you already have the duplicate and move functionality - maybe we can build on top of that. maybe the design could be as following: new field in chart settings to customize masterChartId whenever a chart that is referenced via masterChartId changes, that chart gets overwritten with the changes, but keeps the datasource that is defined can we prioritize this item to be resolved in the very near term?

+1

Hey Tom, that exactly what you said would meet our needs! We want to add MongoDB charts into our scaled product. Every client relies on a different database but the database collections structures are the same. It would be nice to plan one chart, and change dynamically the database/collection parameter in the embedded view like is done with filters!

Thanks for the additional info Brian. We're looking into how best to make this work, but the idea is to have a new "dynamic" data source type which could map to something like "mydb.*" or "*.sales". When rendering a chart using a dynamic data source, you'd need to resolve it to a specific collection that matches the pattern, using an experience similar to filtering. Would this meet your needs?

I'd like to second this idea. We're in a position where we have an application that will have about 100 databases for individual client sites running on the same cluster. Since these clients have individual databases, they'd require unique charts. So if we've got a change to be made to an existing chart, we either need to fix it on one, clone it 100 times, update the data source on the 99 new ones, and update our client application with the new chart ID, OR make that change on the existing 100 charts manually. Being able to have something like a master chart that you could pass a data source to and it fill in the data from it, or possibly even passing the parameters that generate the chart itself as a json file or something (data source, fields, colors, table column width, etc...) and having that returned would be most beneficial to our organization.