defaultColumns per data view

[dalenewman]

Describe the feature: Currently the defaultColumns in Advanced Settings seems to only accept a comma delimited list of column names (e.g. col1,col2,etc). If you have one index pattern or a lot of common fields between your index patterns, this works out okay.

However, if you have two totally different index patterns, a set of defaultColumns is usually only useful for one index pattern and not the other. It might be nice to have a defaultColumns setting for a each index pattern. Perhaps something like this:

[
   { "indexPattern":"_all", "defaultColumns":"commonColumn1" },
   { "indexPattern":"index1", "defaultColumns":"column1,column2,etc"},
   { "indexPattern":"index2", "defaultColumns":"col1,col2,etc"},
]

or

[
   { "indexPattern":"_all", "defaultColumns": ["commonColumn1"] },
   { "indexPattern":"index1", "defaultColumns": ["column1","column2", "etc"]},
   { "indexPattern":"index2", "defaultColumns": ["col1","col2","etc"]}
]

In my case, I loaded a helpdesk ticket index, and also a job application tracking activity index, and they have very few column names in common. So, a set of defaultColumns works great for one index pattern, but just confuses people using the other. A work-around for me is to transform the names of the columns into something common. So, it's not a must-have feature, but would save me some work and offer more flexibility in general.

[michalterbert]

guys, any update, plans?

[bmcconaghy]

@michalterbert sorry for the delay in response. This is a reasonable feature request and is something we would like to implement. We are pretty swamped at the moment, so it will likely be a bit before we can get to this.

[dalenewman]

Thinking about it...

It might be better to have this setting on the index patterns (edit) page. Perhaps a field level setting to indicate that it should show up on the discover page by default. This may be more user-friendly.

[tvlieg]

Is this still considered? We would like to use this feature as well.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

I can see the use case and this would definitely be helpful, It could be an addon to Kibana data views management. However, since this would be only used in Discover, it wonder if a solution like remembering the last columns that were used when selecting a data view (they are no longer called index pattern) in the users localStorage could also be useful?

[ghudgins]

+1 I know of one user who wants it at the Data View level because they want to simplify Discover for their end users (they have a lot of fields from beats). I think localstorage would be useful as well (as soon as any users makes changes to the display...remember them)

[kertal]

@ghudgins do you think there's a use case beyond Discover?

[ghudgins]

right now i'm struggling to think of one outside of Discover that doesn't muddy the waters with data view (index pattern) field popularity. maybe @shaunmcgough or the original poster has thoughts?

Even if it's only a Discover setting I think there's some nice upshot of moving this into the data view level though...

• smarter defaults in ECS
• admins can customize the experience for their users

[shaunmcgough]

This is sort of like the feature in Timeline where you can setup templates for each data view, and each template can have certain fields that show up. In Timeline you can view multiple data views at once, so these are displayed at the same time. In the screenshot attached, you can see an example of how these fields show up. I believe a solution like this would solve the need. It's basically per data view.

[kertal]

@shaunmcgough how does the management for these fields / data view look like?

[shaunmcgough]

It's done through a process called 'event rendering' and there is a tool kit in Security for this. More info can be found here. It's very nice, and we can learn a few things here.

[VijayDoshi]

@kertal let's bring this into the next planning session.

[kertal]

added it to our next week agenda, because I think we should talk about this before to clarify

[kertal]

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.