Add support for field type alias in index pattern

[ruflin]

Elasticsearch has support for the datatype alias: https://www.elastic.co/guide/en/elasticsearch/reference/master/alias.html When using alias fields in an index and creating and index pattern Kibana assigns the exact same capabilities to the alias as the original field. This has the nice benefit that most things just work as expected as querying an alias behaves the same as querying the original field. The disadvantage is that Kibana does not have knowledge if a field is an alias or not.

I'm proposing to introduces a type alias in the index pattern. If Kibana detects an alias field it looks up the capabilities like searchable, aggregatable etc. from the original field and assigns the same behaviour.

Today it's possible to assign 2 different formatters to the original and alias field which I think don't makes sense. If the formatter is changed on the original field, the alias field should automatically follow.

Having knowledge in Kibana that a field is of type alias should also make it possible to solve the problem around that Discovery does not show alias fields #21705. Kibana could fill in the alias fields with the original values if they exists on the fly for example.

On the Beats side we generate the index pattern for Kibana. The current implementation means we have to do the linking of original to alias on the Beats side instead of leaving this to Kibana. Having a type alias would simplify the implementation on our end: elastic/beats#10013

[elasticmachine]

Pinging @elastic/kibana-app

[elasticmachine]

Pinging @elastic/kibana-app-arch

[jtibshirani]

I just filed elastic/elasticsearch#44298 (in the elasticsearch repo), which is a proposal to add field alias information to the response of _field_caps. It would be great to get your feedback on the issue, particularly if the proposed API fits with plans to add alias information to index patterns.

[wylieconlon]

We worked around this in Lens by combining information from the index pattern, field capabilities, and index mappings. It would be great to have this available in one API: #54064

[strawgate]

Today it's possible to assign 2 different formatters to the original and alias field which I think don't makes sense.

We use this functionality to allow "duplicating" a field so we can apply different formatters to the original field versus the alias.

So let's say I have a date field and i want to present the user links to different weather websites. I can alias the date to MyLink1, MyLink2, MyLink3 and have each one have a URL formatter that points to a different destination.

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.

[ruflin]

Reopening as alias field is an existing type in Elasticsearch and as described initial Kibana should support it.

[elasticmachine]

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

[kertal]

I took a look at it, from Kibana side, we don't have information about alias fields, so we would need ES to support it, there are multiple issues for this, I think the most relevant was closed, and we could consider the to reopen it. Setting this to blocked for now

elastic/elasticsearch#49264

[ruflin]

It is suprising to me that Elasticsearch does not expose alias information. @felixbarny This might also be relevant in the case of passthrough fields.

[felixbarny]

As far as I know, an alias field just looks like a regular field in field_caps. So if foo is an alias for bar, you'd get both fields in the field_caps response. Does that solve the main use case you have in mind? If not, why? Adding information to field_caps to identify that a certain field is an alias (and maybe the name of the field it aliases) is probably not too hard™. I suppose the hardest thing is to align on if and how we should do it, and to prioritize the implementation and reviews.

Passthrough fields are also part of the field_caps response (both the namespaced original fields and the top-level aliases).

[ruflin]

I'm proposing to introduces a type alias in the index pattern. If Kibana detects an alias field it looks up the capabilities like searchable, aggregatable etc. from the original field and assigns the same behaviour.

@kertal Can you share what Kibana does today on the above. Have not tested this again since I wrote the issue.

[kertal]

@ruflin Sure! Like @felixbarny said

So if foo is an alias for bar, you'd get both fields in the field_caps response.

We just return what we get from field_caps and therefore you get foo and bar , but you don't know these are technically the same fields. But everything works as expected, only this doesn't

Today it's possible to assign 2 different formatters to the original and alias field which I think don't makes sense. If the formatter is changed on the original field, the alias field should automatically follow.

I'm not sure what's the impact of this enhancement, given that even if we get alias info, it's not a small task to implement a sort of field formatter inheritance.