Changes to Saved Search objects do not reflect in Dashboard without re-adding

[loekvangool]

Kibana version: 5.1.1

Elasticsearch version: 5.1.1

Server OS version: Elastic Cloud

Browser version: Chrome

Browser OS version: macOS 10.12.1

Description of the problem including expected versus actual behavior:
Changes to Saved Search objects do not reflect in Dashboard without re-adding

Steps to reproduce:

1. Create a Saved Search in Discovery; save it and add it to a dashboard.
2. From the dashboard, click on the Edit icon and add a column to the Saved Search; Save it.
3. Go back to the Dashboard that has the Saved Search object in it, it's not updated to show the new column; Refresh, hard refresh, still the update does not propagate.
4. Remove the Saved Search object from the Dashboard, and re-add it. The change is visible only now.

[stacey-gammon]

Confirmed this exists in 5.0 as well.

[stacey-gammon]

As it turns out what should happen is not exactly clear, because saved searches are editable in the dashboard (columns and sort order). Consider the following situation:

• Add a saved search to a dashboard.
• Remove a column
• Save the dashboard.
• Re-open the dashboard.

Should the saved search show the original columns or the edits made to the saved search in the dashboard?

@cjcenizal @uboness @tbragin The answer to this may also come into play with view/edit mode. It is another "edit" that relates to data exploration. If we do preserve these changes made to the saved search inside the dashboard, do we allow interaction with them during Non-Edit mode?

I think the changes should be considered temporary local edits and not stored with the dashboard. I do think however, that the column and sort state should be saved in the url though so someone using a 'Share Snapshot' link will see the same columns/sort order at the time the link was generated.

There would still be a weird experience when directly editing a saved search - saved changes to the search wouldn't be visible until the dashboard was re-opened because the url parameters would override it.

Here is a table of how it could work, assuming we do not store the custom columns with the dashboard, so re-opening will refresh all saved searches back to their previous state.

Table Description
Initial Cols - The columns shown in a saved search when it is first added to a dashboard
Local Edit Cols - Changes made to a saved search inside the dashboard
Saved Cols - Changes made and subsequently saved to that search inside discover (perhaps navigated to via the edit button in the dashboard)
Nav to Dash Cols - The columns shown in the dashboard when you navigate back to it (not using Open but the tab link. The distinction is important because open kills any local url state while navigating preserves it.
Shared Cols - The columns shown in a dashboard shared at this point via the Share Sanapshot link
ReOpen Dash Cols- The columns shown in the dashboard when it is re-opened (all local state is lost).

Initial Cols	Local Edit Cols	Saved Cols	Nav to Dash Cols	Shared Cols	ReOpen Dash Cols
A	-	B	B	B	B
A	B	C	B	B	C

[stacey-gammon]

Duplicate of #4884

[tbragin]

via @GrahamHannington in #4884

Perhaps this is working as designed, but it tripped me up (Kibana 4.1.0, build 7467).

I saved a dashboard that included a saved search.
I opened the saved search, added a column to its Documents table, and then saved the updated search.
I opened the dashboard, expecting to see the search with the new column. Nope, not there.
I looked at the JSON of the dashboard definition, and could see why that column was missing: the object in the dashboard definition for the search contains a "columns" property that lists the columns for the search. That list reflects the columns in the saved search when I added the search to the dashboard.

I considered editing the dashboard definition JSON to insert the missing column; I even considered deleting the "columns" property, to see if Kibana would default to using the (latest) set of columns in the saved search. In the end, though, I played safe, and simply deleted that search from the dashboard, re-added the search, and then saved the updated dashboard.

Is this - saving the columns of a search's Documents table in a dashboard definition - working as designed? Could I have simply deleted that "columns" property from the corresponding object in the dashboard definition JSON, or would that cause problems? (I haven't tried that; I need to move on.)

[tbragin]

via @anhlqn

I really don't want to remove and readd a saved search to every dashboard whenever I update that saved search. Yet directly editing dashboard JSON is a workaround for me.

[tbragin]

via @PavelVanecek

Just ran into this issue using Kibana 4.4 (dev build from commit 26fce6e). Removing the search from dashboard and adding it back helped.

[weltenwort]

During a recent attempt to clean up some code of the document table I stumbled across this effect and would propose another solution: Disable editing the columns directly in the dashboard.

Like with visualizations, the user can always click the edit icon in the upper right corner of the panel to open the saved search in Discover, make changes and save it in order to have the changes reflected in the dashboard.

I know this is not possible with the current document table, but it will be possible with my cleaned up code.

[Bargs]

Like with visualizations, the user can always click the edit icon in the upper right corner of the panel to open the saved search in Discover, make changes and save it in order to have the changes reflected in the dashboard.

What if the user don't have write permissions on the saved search? I feel like users still might want to make transient modifications to the columns as they interact with the dashboard. Same thing especially goes for sorting, which suffers from the same problem as column selection in this ticket.

[GrahamHannington]

Not miffed, just curious: why was #4884 closed as being a duplicate of this more recently opened issue? This seems counterintuitive to me: to close an existing issue as being a duplicate of a newly opened issue.

One reason I’m curious: #4884 was acknowledged as a bug in September 2015. Could I have done more to get that issue acted upon?

[epixa]

@GrahamHannington Sometimes a newer ticket for the same issue may contain more relevant information, or may have more inbound links from other tickets either on the Kibana repo itself or from out in the world, so we just try to use our best judgment about consolidating information into that ticket rather than relying purely on ticket age. When we do that, we try to copy over the relevant information from the original ticket as well, like here: #9523 (comment)

I don't think there was anything wrong with your original ticket. Sometimes it just takes the right person stumbling on an issue to help move it along. In this case, @stacey-gammon took it upon herself to dig into possible solutions to this issue, and she may not have been aware of the original.

We also have better processes in place now for triaging tickets that come in than we did when you filed the original ticket, and that likely contributed to the lack of attention the original ticket was getting.

[stacey-gammon]

I think we can leave sorting as is, but get rid of the ability to remove and reorder columns for saved searches inside a dashboard panel.

We would be removing the ability to view less data, or data in a different order, but not more data, so this feels okay to me, and much preferable to the current situation of potentially missing out on new data because your saved search didn't update with a new column, for instance.

@Bargs What do you think about this? If we left sorting configurable but took out reordering and removing columns?

[stacey-gammon]

If we can agree on removing the ability to remove and reorder columns from a dashboard, I have a PR ready to go.

@epixa, @tbragin, @alexfrancoeur -- do you guys have any thoughts on this?

[Bargs]

I feel like that's ignoring the larger problem. Won't people be just as confused if they change the sorting on a saved search, open a dashboard with that saved search, and the sorting is out of date?

I may not fully understand the issue. I assumed the root cause was the fact that the dashboard's app state is out of sync with what's saved. But I just realized the dashboard saved object is maintaining it's own column selection and sort information about each saved search which seems to only get updated when the search is added to the dashboard. Why is that the case?

[weltenwort]

@stacey-gammon #10681 also makes it easy... just remove the lines in the panel that provide the column manipulation functionality. Hope we didn't duplicate too much work there.

[stacey-gammon]

Nice @weltenwort, once the discover refactor PRs are in place I'll adjust the logic.

I just realized the dashboard saved object is maintaining it's own column selection and sort information about each saved search which seems to only get updated when the search is added to the dashboard. Why is that the case?

@Bargs, you are correct, the dashboard is saving the state so even when the dashboard is reopened, it's not refreshed. Why this is the case, I don't know, but my first comment on this issue suggested a solution where we don't do that. (fwiw we also store our visualization legend color overrides with the dashboard) .

I think the changes should be considered temporary local edits and not stored with the dashboard. I do think however, that the column and sort state should be saved in the url though so someone using a 'Share Snapshot' link will see the same columns/sort order at the time the link was generated.

There would still be a weird experience when directly editing a saved search - saved changes to the search wouldn't be visible until the dashboard was re-opened because the url parameters would override it.

Here is a table of how it could work, assuming we do not store the custom columns with the dashboard, so re-opening will refresh all saved searches back to their previous state.

But note that even with that change, there is still the weird experience of clicking the edit button on a saved search, adding a column, saving, navigating back to the dashboard and not seeing that added column. Because of that I came around to @weltenwort's suggestion of not even allowing those edits.

We could get rid of storing sort state with the dashboard and keep it only in temporary local state - I don't really feel strongly either way.

I do think we should allow Sort because removing the ability to sort would be restricting data exploration. The user might not be able to see some rows that would otherwise go off the screen. Perhaps you could say the same about column reorder, but the scale of the problem is different because there could be 500 rows.

Also, the user has the ability to fix the wrong sort state right in dashboard -- they can't do that with missing columns.

[tbragin]

@stacey-gammon Fwiw, I agree we should keep the local sorting behavior.

In general, I'm +1 with the approach you outlined, but I haven't looked at the PR yet. Perhaps @alexfrancoeur has time to check it out and weigh in? #10920

[alexfrancoeur]

@stacey-gammon ++ on keeping the sorting behavior local to the dashboard. The PR looks good and there is a quick link for editing the saved search to allow for a "quick edit".

The use case for editing a saved search directly from a dashboard gets even more difficult with the introduction of view/edit mode. It's hidden that much more. I'd be interested in how often the use case is used in general. As I see it, the benefit here is for multiple users to start with the same saved search and then adjust the results for their own personal dashboard.

Visualize has a concept here that we may be able to re-use to address the above mentioned use case. If you look at the below screenshot, the visualization is tied to the saved search by default. However, if you double click the link the saved search becomes local to that visualization.

We could introduce a similar concept to #10920 where the default will link to a saved search and you cannot customize columns. However, if you unlink - it becomes local to the dashboard and you can make modifications. This approach would cater to both use cases but I'm not sure of the implementation complexity.

That all being said, as a new user - I'd expect a saved search added to be exactly what I saw in discover and would not necessarily expect to modify. We have to think of the existing user base here and determine if it's worth the extra effort to keep the customization functionality in one fashion or another.

[stacey-gammon]

I'd be interested in how often the use case is used in general.

Agree it'd be great if we had stats on how often this was used, but I don't think we do.

As I see it, the benefit here is for multiple users to start with the same saved search and then adjust the results for their own personal dashboard.

Yea, but as long as users have write ability on the .kibana index, then they can workaround it (edit the saved search, or create a new one and swap it out). Unfortunately read only users won't be able to get around the new restriction.

However, if you unlink - it becomes local to the dashboard and you can make modifications. This approach would cater to both use cases but I'm not sure of the implementation complexity.

Very interesting idea but I'm worried the UI/UX and implementation complexity would not be worth it at this point. In the very long run, when we flatten the document structure so all visualizations are local to a dashboard, then we can allow these type of inline edits. So this is a bit of a stop gap solution (well it might be a long gap, haha). I just don't have a super clear UI in mind that would explain to the user that they will stop getting any column updates to this saved search as soon as they modify the columns in dashboard. Feels like a complicated concept. Thoughts from design team @snide @cjcenizal?

@epixa, is there any precedent on removing functionality we suspect is not often used? And if it does result in push back, attempting to add that functionality (in a better way, like Alex suggested) back in? Without hard stats on what is and what isn't used, we are somewhat shooting in the dark, but in my mind, the bug resulting from this is much worse then the benefit of being able to adjust columns.

[epixa]

Since this problem goes away once we flatten visualizations out into dashboards and since the issue has existed in Kibana since 4.1.0, if not earlier, why the sudden need to change this? I do agree that the behavior as it stands now is not ideal, but given how Kibana dashboards work right now the solution is not straightforward and comes with a lot of risk of breaking people's workflows in unexpected ways.

[stacey-gammon]

why the sudden need to change this?

It feels like a bug and I wanted to fix it given that quite a few people have run into it.
Well... at least 4 or 5 people judging by this ticket. :)

But you make a good point. Sounds like the priority is be very careful when removing functionality so we should continue to postpone this. Really makes me wish we had click stats.

[Bargs]

But note that even with that change, there is still the weird experience of clicking the edit button on a saved search, adding a column, saving, navigating back to the dashboard and not seeing that added column. Because of that I came around to @weltenwort's suggestion of not even allowing those edits.

Just for the record, I actually prefer the original solution you proposed @stacey-gammon. The issue I have with disallowing column manipulation is that it only solves one specific side effect of the underlying problem. The root problem is that a user's app state is very sticky and hides changes to the underlying saved objects. This problem affects every kibana app (as you pointed out here) so we should figure out how we can handle it in a more universal manner. Perhaps we should store fewer things in the URL. Column selection for instance feels like it should be in memory, clearable with a simple refresh. But then we lose the ability to share the URL with the current column selection. I'm not sure what the best solution is.

[loekvangool]

Just wanted to throw in a thought. Maybe it's enough to keep all current behavior (as of 5.5), but add a button to the dashboard Update from Saved Search on the right-hand side alongside the existing ones:

It would then overwrite all local customizations.

I was working with some Dashboards and had to update the Saved Search a couple of times in a row. Basically the only thing I did was removing + readding the Saved Search in the dashboard. A button to make that happen in 1-click is what I'm suggesting.

[weltenwort]

That does not sound too bad, but IMHO we should be careful to cement these "mixed" situations where some state comes from the saved viz and some from the dashboard. If we make "update from saved viz" a manual step, it might be less confusing if there was no "automatic" application of changes from the source at all.

At the very least there should be a marker to indicate whether the state differs from what is stored in the saved viz.

This could also be seen as a step towards #4489.

[stacey-gammon]

I agree with @weltenwort - we need to be careful we are consistent across the board with the mixed state. Perhaps a generic "reset" button on every panel, that will remove all the custom dashboard state for that panel - including things like color choices for labels, etc.

[stacey-gammon]

Don't know why it took me so long to fully grasp this problem, but I believe I have found a simple solution with #14452. This causes the saved search state to behave the same as visualization state that can be overridden such as colors. Changes should propagate to the dashboard except when a column or sort is explicitly overridden. I believe this will solve most of the problems we see with this issue.