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
This method is most excellent for dynamically updating filters. However, the problem we run into is when users deploy custom saved views, then the filters saved by the user should take precedence.
Within the extension logic, we can inspect the "document.url" and make a determination of a custom saved view by existence of the @ sign. And this works well. The time that this doesn't work is when we are embedding a view and the user chooses to set the custom saved view as default. At this point, we never see the @ sign in the URL.
The text was updated successfully, but these errors were encountered:
Hi Jeff,
We have some upcoming work related to handling Custom Views in the Extensions API a little bit better. Your request makes complete sense and we will incorporate it when we start the work to improve Custom Views support. Thanks!
This method is most excellent for dynamically updating filters. However, the problem we run into is when users deploy custom saved views, then the filters saved by the user should take precedence.
Within the extension logic, we can inspect the "document.url" and make a determination of a custom saved view by existence of the @ sign. And this works well. The time that this doesn't work is when we are embedding a view and the user chooses to set the custom saved view as default. At this point, we never see the @ sign in the URL.
The text was updated successfully, but these errors were encountered: