Allow the injected filter for authenticated embedding to be injected as the first filter in pipeline
When you embed a chart with authenticated access you have the option to inject a function that returns a MongoDB Query to be injected as a filter on the chart. In this function you have access to the context object which provides info about the current user (token), this gives you the ability to filter the data per tenant in case of multi-tenant applications, but since this filter is only applied as chart filter and not as filter in the aggregation pipeline of the chart or as filter in the view used by the chart, it's really difficult to hit multi-tenant indexes (indexes that have the tenant id as a prefix) especially if the chart requires data processing in its pipeline. Provide the ability to select where this injected filter is applied for example as the first step in the aggregation pipeline of the chart, as a filter in the view that is used by the chart or as is now.
Kyriacos
shared this idea
-
Prakash
commented
As our collection data is not optimized/shaped for the needs of the data visualizations we want, we have defined views for the same. They are defined on a base collection along with an aggregate pipeline having variety of stages, i.e. $match, $lookup, $addField, $group, $project etc.
Whether it's our db view or chart view - the stages of the view pipeline make it first, then the pre-filters for embedding charts, which is where we set something like ownerId to a value at runtime, based on the user loading an Atlas dashboard, embedded in our web application (same as @Kyriacos mentioned).
I was exploring, if the preFilters i.e. for ownerId with dynamic value is added under a $match stage, as the first stage in the view pipeline.
With that, data will be filtered right from the base collection, on which the db view is defined. This will make the queries for charts process just a slice of data instead of the whole set, and would result in faster query response.
A MUST for consideration.