Lift restriction of not allowing '_'-prefixed fields. Close #2551

[algesten]

As long as Elasticsearch does not enforce this rule, neither should
Kibana.

[elasticsearch-release]

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then say 'jenkins, test it'.

[rashidkpc]

Sorry, this is a defined convention in Kibana that we're not planning to change. _ fields are ambiguous, we don't know if they're part of the _source or one of elasticsearch's meta-data fields, further we have no way to handle conflicting fields. Thanks

[algesten]

Why do you consider it necessary for Kibana to handle that ambiguity? Elasticsearch doesn't even warn you if you call a field "_timestamp" for instance. The user is left responsible for shooting themselves in the foot.

Would you consider this request if I code
it to be behind a configuration option that is off by default. I.e "allowUnderscoreSourceFields" with big warning signs that the user may get strange results if their name clashes with an internal field.

[rashidkpc]

Sure, as long as it was off by default and we keep the warning in the doc_viewer. I want everyone to understand this is not recommended and will likely lead to serious bugs down the road.

That option should go in the advanced settings editor.

[algesten]

Great! I'll take a stab at it soon.

[AdeMiller]

Did this get resolved? It's just bitten us as we moved to Kibana 4.

[algesten]

I've been meaning to look at it for ages. it's not a big job, but other work things have come in the way.

[f0o]

How are we standing on this after 6 years and a massive increase in usage of _ prefixed fields (systemd, GELF, ...)?

Still no plans on supporting it without having to fork kibana and cherrypick this PR?