[BUG] Filters in URL of saved searches are lost while page loading #7677
Assignees
Labels
bug
Something isn't working
Comments
|
I'm having the same experience as @jonashellmann ⬆️ on version 2.13.0. Filters are lost when I use "Share PERMALINK" or just copy-paste URL to different tab. |
|
@shobull Thanks for the feedbacks and report. I think yours is a bit different. The error is in the opensearchDashboardsUtils.plugin.js file. This suggests that there's an issue with restoring a URL state. Could you try:
See if the error is gone. Let us know. |
|
Hi @ananzh, I tried Firefox & Chrome (latest stable releases)
None of above helped. I'm seeing the same behaviour as @jonashellmann (losing all |
|
Hello @ananzh I'm also able to replicate this behavior, as are multiple other co-workers across multiple computers and multiple browsers. We're running OpenSearch 2.13 in AWS. Thanks. |
|
We are also seeing the same error as @shobull. Sharing via the "Share" button and selecting "SNAPSHOT" results in the error message that shobull mentioned:
Users are using a mix of Firefox & Chrome, we're running OpenSearch 2.16 and OpenSearch-Dashboards 2.16. |
FWIW, we solved this by disabling the option "state:storeInSessionStorage" in Advanced settings for OpenSearch-Dashboards. Users then had to recreate the shared URLs. We found the cause here: elastic/kibana#126907 (comment) |
|
@vinylen I'm able confirm the same behavior with that setting. The answer on that linked issue is "working as intended, won't fix." So, the intention is that shared links just don't work when session storage is turned on? That seems like a terrible response. At the very least turning on that setting should disable the share functionality so that users don't get confusing error messages and bad links. To add to this situation, we're having to disable that setting every few days. Either some user is resetting it (which can't be prevented as it's impossible to prevent most users from accessing and changing those settings until some nebulous future dashboard rework is done.), or some automated process is resetting it. Which is its own problem. |
|
We are also facing the same issue in OpenSearch dashboards 2.15. The query filters are lost when the page is loaded. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When I want to open a saved search and add another filter to this saved search, this was possible by adding this information inside the URL. This worked with OpenSearch Dashboards
2.9and prior. When loading OpenSearch Dashboards with such an URL for the first time in a browser tab, this filter information will get lost.The behaviour is different (and working) if you enter the URL into a browser tab where the
Discovertab of OpenSearch Dashboards is already opened.To Reproduce
Steps to reproduce the behavior:
Openbutton in the top right cornerOriginCountry is USfor the saved search[Flights] Flight LogSharebutton in the top right corner with theSnapshotoption activated.Expected behavior
Since the filter is part of the copied or generated URL in the
_qURL parameter the filter should be applied to the saved search when opened in a new browser tab.However, after having the filter actually visible for a very short time, it disappears and the URL doesn't contain this specific part in the
_qURL parameter anymore.If you paste the same link from before into this browser tab where OpenSearch Dashboards is already loaded, the filter is applied and will not get removed so there must be some issue with the initial page loading.
OpenSearch Version
2.16
Dashboards Version
2.16
Plugins
Query Workbench
Reporting
Alerting
Anomaly Detection
Maps
Security Analytics
Search Relevance
Machine Learning
Host/Environment (please complete the following information):
Additional context
?_q=(filters:!()instead of?_q=(filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:d3d7af60-4c81-11e8-b3d7-01146121b73d,key:OriginCountry,negate:!f,params:(query:US),type:phrase),query:(match_phrase:(OriginCountry:US))))The text was updated successfully, but these errors were encountered: