Permissions for dropdown values of parameters should be governed by query's ACL

[arikfr]

Currently to be able to load data for dropdown values you need read access to the data source these values came from. This goes against our current plan of allowing anyone with access to the query to be able to interact with it.

Based on the above, we should change the way we assert permissions for dropdown values to allow access if the user has access to the query which uses them.

This means the API should change to something like:

/api/queries/<parameterized query id>/dropdowns

And there we should look up all the relevant queries and return needed values.

Of course that's just one idea.

[rauchy]

I've been playing around with this and I tend to think we would need a dedicated endpoint for query-based dropdowns used in embeds and public dashboards. The reason is that dropdown values will be obtained in 3 different situations:

1. At the time a user is creating the query and setting up parameters - the dropdown query is not yet associated with the parent query (and the parent query might not even be persisted yet). In this case, there's no way to find an association between the two queries and you just need to be able to directly access the dropdown query.
2. When validating parameters - this happens server-side and we already made sure there is an association between the parent query and the dropdown query when the query was created.
3. After an embed (or dashboard) is created and shared - then, a (non-logged-in) user should be able to select from the dropdown values and for that we would need something like /api/queries/:parent_query_id/dropdowns/:dropdown_query_id

Let me know if you have any thoughts on this.

[arikfr]

Sounds right.

…

--  Arik Fraimovich

On Wed, Mar 06, 2019 at 2:35 PM, Omer Lachish < ***@***.*** > wrote: I've been playing around with this and I tend to think we would need a dedicated endpoint for query-based dropdowns used in embeds and public dashboards. The reason is that dropdown values will be obtained in 3 different situations: * *At the time a user is creating the query and setting up parameters* - the dropdown query is not yet associated with the parent query (and the parent query might not even be persisted yet). In this case, there's no way to find an association between the two queries and you just need to be able to directly access the dropdown query. * *When validating parameters* - this happens server-side and we already made sure there is an association between the parent query and the dropdown query when the query was created. * *After an embed (or dashboard) is created and shared* - then, a (non-logged-in) user should be able to select from the dropdown values and for that we would need something like /api/queries/:parent_query_id/dropdowns/:dropdown_query_id Let me know if you have any thoughts on this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub ( #3467 (comment) ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/AAEXLC6EkfvhbPnoNiwGXnhGyqhXEfYMks5vT7YPgaJpZM4bDN2Y ).