Add a configuration to set the query bar placeholder text

[trevan]

This allows administrators to customize the placeholder text to fit their environment better. Our data doesn't have the "status" or "extension" field so if one of users tries to follow the example, they'll get no data. With this, I'll be able to change the text to show examples that fit our data.

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[timroes]

Jenkins, test this

[timroes]

Since we know, that this can't change while the template is loaded, please use bind-once syntax: {{::queryBar.searchPlaceholder}} (the same for the other usages of course too)

[trevan]

Done

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[Bargs]

I understand the desire for this, but I'd hate to add another advanced setting for something so trivial. Is there an alternative, more generic placeholder text we could use that would solve your issue? @lukasolson is working on autocomplete for the query bar right now, the backend of which will give us better introspection into each user's fields and their values, so we could potentially customize this placeholder text dynamically in the future.

[timroes]

I think a customization of the message might still be beneficial in several cases. I've often seen use-cases in trainings and with users, where they try to enter exactly that query up there, and wonder why nothing happens. Since in many companies the actual maintaining and "caretaking" of Kibana might be done by different people than the actual usage, I think it's a nice addition, that those could configure that message, to maybe customize it more to their instance.

Also I am not sure if we should consider adding advanced settings a bad thing. I think a good software stays customizable in the end. I think the actual issue here would rather be our structure of the settings page (see #14791).

[trevan]

@Bargs, it might be possible to dynamically build the sample query using fields in the index pattern available on the page. But then it might show really weird fields. Our system has >2k fields and many of them are sparse so it would need to be intelligent to find fields that are more common.

Our setup will probably have the autocomplete feature turned off so that won't be a good replacement. The existing autocomplete in the filter creator is already slow and I believe the auto complete in the query bar is based off the same logic so it will be too slow to be useful.

As for a generic replacement, it is nice to have an actual example query. Back a few versions ago when the placeholder didn't really show up (I think this was when it was defaulted to '*'), I know several people who had no idea what to enter in there. Since the placeholder has been visible, I haven't seen or heard of any issues except for typing in fields that don't work.

[trevan]

@Bargs, @timroes, I just remembered that the Discover page shows some example queries when no data is found. I'd also like to change that text. I don't know if that fits as a config option since the text looks to be a little bit longer. Maybe Kibana should have a plugin hook to edit the text in the placeholder and on Discover?

[Bargs]

Also I am not sure if we should consider adding advanced settings a bad thing. I think a good software stays customizable in the end. I think the actual issue here would rather be our structure of the settings page (see #14791).

@timroes I disagree. We've been extremely lax about advanced settings in the past and we're paying for it now. Every single advanced setting is a promise to our user base which we can't break except in major versions, and even then it's hard to take things away. This makes technical debt significantly harder to clean up because it leaks implementation details that really shouldn't be exposed to the user in the first place. Better organization of the advanced settings page doesn't solve this problem. And this isn't a theoretical argument, I've been bit by old advanced settings at least twice in the last couple weeks.

I agree this is a totally reasonable sounding request. But the same argument could be made for literally every piece of static text in Kibana (note Trevan's latest comment, he also needs to customize the 0 results page). If we want to start making our templates customizable, we shouldn't do it by adding a bunch of ad hoc advanced settings. We should tackle the problem with a proper solution (and we already are in a way, customized strings could piggy back off of the i18n system).

[lukasolson]

To me, this seems like it should be an extension point rather than an advanced setting. We're working to make it possible for you to provide your own "query bar" implementations and languages so that you can have complete control over the process. Adding another advanced setting for something like this seems in conflict with the direction we'd like to head here.

[timroes]

This sounds like we can close this PR, since the general opinion is, not to have this in an advanced setting. Is there any issue that we could follow up for the extension point of the query bar?

[trevan]

I'm fine with building an extension point but how would you like it done? @lukasolson's comment about allowing people to add their own query bar is useful but I think a little overkill to just change the placeholder text. Plus, I need an extension point to also change the text on the discover page.

[Bargs]

@trevan sorry this has languished for so long. I was just re-reading the thread and it looks to me like you have a need for a more general ability to customize the text in the Kibana UI. I'll be honest, I think it will be an uphill battle to get this implemented. It seems like a very niche request to me, but at the same time it'll be very difficult to implement cleanly. Discover isn't really built to be extended today.

Down the road we'd like to turn the query bar and the doc table into components that can be customized and dropped into a dashboard or canvas, similar to the new input controls visualization. I think that might eventually give us a good place to put this kind of customization. Before we do that, I can't think of a good way to implement what you're asking for.