[BUG] URL cannot be saved anymore

[huehnerlady]

Describe the bug

Earlier versions you were always able to save the URL as a bookmark - or also adapt the URL to eg. switch between development and prod and not loose your filters.

Now when you do that all the filter reset.

To Reproduce
Steps to reproduce the behavior:

1. Go to Discover
2. Click on new filter
3. set a random filter
4. Add some fields to form a table
5. copy the URL in the address bar
6. paste it in a new window
7. the filter and the fields in the address bar are gone

Expected behavior
I expect that these items are still there when we reuse the URL - just like it worked before. You can share the URLs via the share button, which is a pain - especially when creating a bookmark - but it is possible. It is not possible however to create a query for dev and then switch the host to prod

Dashboards Version
v2.5.0

Plugins

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: OSX 13.4.1
• Brave Version 1.52.130 Chromium: 114.0.5735.198

[mustafaazad03]

Hi,
is this issue still open? can I work on this?

[huehnerlady]

I haven't seen any updates so I am happy for you to go ahead :)

[sourabh-bhatt]

Is the bug still coming or sorted?

[huehnerlady]

the bug is still coming

[AMoo-Miki]

I believe Discover is being revamped and this would be addressed there. @ashwin-pc might have more information.

[ashwin-pc]

@huehnerlady I have a suspicion that this might be an issue with how the link is stored rather than the URL itself. Here is a URL to the playground website that has the filters applied and a few columns selected:

https://playground.opensearch.org/app/discover#/view/eed52100-6fa7-11ed-a8ec-958f39714b93?_g=(filters:!(),query:(language:kuery,query:''),refreshInterval:(pause:!f,value:900000),time:(from:now-7d,to:now))&_a=(columns:!(category,sku,taxful_total_price),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:ff959d40-b880-11e8-a6d9-e546fe2bba5f,key:category.keyword,negate:!f,params:(query:'Men!'s%20Clothing'),type:phrase),query:(match_phrase:(category.keyword:'Men!'s%20Clothing')))),index:ff959d40-b880-11e8-a6d9-e546fe2bba5f,interval:auto,query:(language:kuery,query:''),sort:!())

This URL can be corrupted depending on the way you store it (e.g. markdown) which is why the share functionality exists. Does this URL work for you?

Another reason for this might be because f something you mentioned in the issue description. When switching from dev to prod environments, the necessary indexes or other state information is not valid for the new environment. This will prevent the app from loading the state correctly and clear out all the filters and columns even if they are valid.

[huehnerlady]

@ashwin-pc we use Opensearch for a while and changing the stage worked for a long time, it just hasn't stopped working recently.

Our stages are all the same, so index etc. are also available.

Is there another possibility to export/import the filters somehow as a workaround? It is super frustrating if you clicked together quite a complex filter setup and then you have to do the same AGAIN in the different stage

The link works for me, do you have a different stage you can manipulate the link to?
Does this mean we need to change the setup to change the way we store things?

[ashwin-pc]

Hmm, i dont know what could cause such a thing, especially since discover simply loads the state stored in the URL. So if you are able to load the URL I shared, you should be able to load the the same when you moved between stages. Do you have a sample URL i can look at to see what might be different from mine?

Do you also happen to know which version broke for you? i.e. which version were you on and which did you move to?

Also If you want to take a stab at fixing this, i'll be happy to help you contribute a fix :)

[huehnerlady]

Our URLs do not look like that anymore, but more like this:

https://<host>/_dashboards/app/discover#/?_g=h@37c70d4&_a=h@1843b5e

so it does not reveal the filters etc. in the URL
When I then change the stage, all filters are gone.

In the rare occasions where I do have the other type of URL:
Example:
https://<host>/_dashboards/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!f,value:300000),time:(from:now-7d,to:now))&_a=(columns:!(service,message,stack_trace,request_path),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:f0b0f300-8812-11ec-b707-ef8e772da31b,key:service,negate:!f,params:(query:foo),type:phrase),query:(match_phrase:(service:foo)))),index:f0b0f300-8812-11ec-b707-ef8e772da31b,interval:auto,query:(language:lucene,query:''),sort:!(!('@timestamp',desc)))

Example after changing stage:
https://host/_dashboards/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!f,value:300000),time:(from:now-7d,to:now))&_a=h@50057b0

I can show the following behaviour:

Here you can see our query.

After I change the stage, I see this:

I need to then choose the same index:

which would be ok, but the field name and value is also gone

[ashwin-pc]

Oh i see the issue. So the URL you provided is a shortened URL. The way the app makes these URL's is by storing the state information on the browser storage and using the key for that stored value in the URL. This way the URL is smaller. The downside to this approach for your use case is that when you switch domains, the same key does not exist for the new domain. So when the app loads and looks for the key, it is not able to find it for the new domain and does not load the state information correctly.

Basically, when the URL works as follows:

https://<host>/_dashboards/app/discover#/?_g=<GLOBAL_STATE>&_a=<APPLICATION_STATE>

GLOBAL_STATE or APPLICATION_STATE can be the raw state thats rison encoded or a key to the stored state value. if it is the raw state, this can be moved across domains, but if its the saved key, it cannot since the new domain does not have the key.

[huehnerlady]

Oh i see the issue. So the URL you provided is a shortened URL. The way the app makes these URL's is by storing the state information on the browser storage and using the key for that stored value in the URL. This way the URL is smaller. The downside to this approach for your use case is that when you switch domains, the same key does not exist for the new domain. So when the app loads and looks for the key, it is not able to find it for the new domain and does not load the state information correctly.

Basically, when the URL works as follows:

https://<host>/_dashboards/app/discover#/?_g=<GLOBAL_STATE>&_a=<APPLICATION_STATE>

GLOBAL_STATE or APPLICATION_STATE can be the raw state thats rison encoded or a key to the stored state value. if it is the raw state, this can be moved across domains, but if its the saved key, it cannot since the new domain does not have the key.

Ah that makes sense. But how can I keep Opensearch from shortening the URL? Is that a setting in my account? Or a setting in Opensearch itself?

[ashwin-pc]

This is enabled by the state:storeInSessionStorage setting in Advanced settings. It should default to false but in your case seems to be true.

[huehnerlady]

@ashwin-pc that was actually enabled, so thank you very much for your help. The URL now looks different, but I do get the same error when changing THE URL from eg. dev to prod, even though the stages are configured complete the same

[ashwin-pc]

GladI could help :) As for the error that you are seeing now, are there any errors visible in the browser console window? Or can you give me an example of the new URL's?

[huehnerlady]

@ashwin-pc
So the first stage url would be:

https://opensearch-logging.dev-stage.[...]/_dashboards/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:now))&_a=(columns:!(level,message),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:f0b0f300-8812-11ec-b707-ef8e772da31b,key:level,negate:!f,params:(query:WARN),type:phrase),query:(match_phrase:(level:WARN)))),index:f0b0f300-8812-11ec-b707-ef8e772da31b,interval:auto,query:(language:kuery,query:''),sort:!())

And when I change dev to prod I get

https://opensearch-logging.dev-stage.[...]/_dashboards/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:now))&_a=(columns:!(level,message),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!t,index:f0b0f300-8812-11ec-b707-ef8e772da31b,key:level,negate:!f,params:(query:WARN),type:phrase),query:(match_phrase:(level:WARN)))),index:'60f87050-962a-11ec-8a5d-c38e322d0273',interval:auto,query:(language:kuery,query:''),sort:!())

[ashwin-pc]

So it looks like the index pattern id changes between the two stages for you, which causes the error. If you look at the URL's that you shared index:f0b0f300-8812-11ec-b707-ef8e772da31b is the index pattern ID in both the filter and the actual index selected (there are 2 occurrences of this in the URL). But in the second URL, the filter still has the same index, but the index pattern used by the app is different, and in your case missing. Hovering over the Error should show you that message. Here is where this happens: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/2.9/src/plugins/data/public/ui/filter_bar/filter_item.tsx#L284-L299.

You can see a similar result when you change the index pattern to one which does not have the level field. This should show you a warning instead.

[huehnerlady]

@ashwin-pc thanks for your help. As this worked before, what can I do that it will work again? Can my admin change the idex pattern ID manually somehow? Or can we change something else which will enable a URL swap?

[ashwin-pc]

@huehnerlady yes, when you create an index pattern, you have the ability to set a custom index pattern id. Doing that on both your staging and prod environments should help you do this switch.

Also i'll be closing this issue since it looks like this should mitigate your problem. Feel free to reopen if you face any other issues.