You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With Query Library and Query History, we store queries for a specific datasource to be used at a later time. However, datasources are not guaranteed to be permanent - they can be removed or the person can lose access to them. We need to think of what to do for these various perspectives, balancing UX concerns with security concerns.
Note: Deleting a datasource, then recreating it with the same UID won't apply here. The queries will always point to the datasource by UID, even if it is deleted and recreated after the query was saved.
Note 2: To make it easier to talk about, lets split queries in these features by temporary vs saved. Temporary queries are queries in query history that have not been starred. Saved queries are either starred queries in Query History or anything in Query Library.
Potential Scenarios
Deleted datasource: User creates content for a datasource, and then that datasource is deleted.
Assumption is that user would still want that content in starred query history and in the query library.
Proposed solution: Don't show non-saved queries for deleted dashboards. Saved queries can have two options - either transfer the query to a datasource of the same type (no expectation of validation ahead of time) or copy the query JSON to the clipboard to be manually moved.
Losing access: User creates content for a datasource, and then loses access to the datasource
Proposed solution: User would not see their content in saved or temporary contexts. It would show up in the query library for people with access to that datasource
Lost and regained access: A user creates content for a datasource, then loses access to it. The datasource is later deleted and re-created and the user then does have access to it
The user would see this content. We would not care about historical access, only current access levels
The text was updated successfully, but these errors were encountered:
Proposed solution: Don't show non-saved queries for deleted dashboards. Saved queries can have two options - either transfer the query to a datasource of the same type (no expectation of validation ahead of time) or copy the query JSON to the clipboard to be manually moved.
I like it. It's clear what happened and gives the user options to recover. There used to be a similar pattern in alerts (I don't see it anymore though). You can see a screenshot in a proposal for this design doc. There's a box telling what happened and the user can choose from various options.
Losing access: User creates content for a datasource, and then loses access to the datasource
Proposed solution: User would not see their content in saved or temporary contexts. It would show up in the query library for people with access to that datasource
+1. CC @kylebrandt Do you know how easy it'd be to filter out resources based on permissions? I might be slow if we'd need to do a search and check for permissions for each query template's data source(s) 🤔
With Query Library and Query History, we store queries for a specific datasource to be used at a later time. However, datasources are not guaranteed to be permanent - they can be removed or the person can lose access to them. We need to think of what to do for these various perspectives, balancing UX concerns with security concerns.
Note: Deleting a datasource, then recreating it with the same UID won't apply here. The queries will always point to the datasource by UID, even if it is deleted and recreated after the query was saved.
Note 2: To make it easier to talk about, lets split queries in these features by temporary vs saved. Temporary queries are queries in query history that have not been starred. Saved queries are either starred queries in Query History or anything in Query Library.
Potential Scenarios
The text was updated successfully, but these errors were encountered: