Add label and icon to nested fields in the doc table

[Bargs]

Summary

Fixes #49842
Depends on #54042

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

- [ ] This was checked for cross-browser compatibility, including a check against IE11

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
  - [ ] Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
  - [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

- [ ] This was checked for breaking API changes and was labeled appropriately

• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[Bargs]

This isn't going to work, it can create false positives. I think I'm going to have to add nested fields to the index pattern.

[timroes]

Both ways sounds rather "horrible" :D If we add nested fields to the index pattern, we would make sure they not surprisingly pop up in any editor (I'd assume we give them a special type nested, that we can filter for?). Also I wonder if we need to make some adjustments to the index pattern management UI, so you cannot have an edit page for those, since it wouldn't make any sense?

But triggering false positives sounds also like a horrible idea :D Question for my understanding: Wouldn't the field above not need to match exactly the nested.path of another field? since it should be the nested root itself, we must have that as an exact path somewhere? Wouldn't that also eliminate the false positives?

[Bargs]

If we add nested fields to the index pattern, we would make sure they not surprisingly pop up in any editor

I think as long as the searchable and aggregatable flags are set to false on the field it won't pop up in places where it shouldn't. I checked KQL autocomplete, the filter editor suggestions and the vis editor and they all hide it correctly.

That's a good point about the edit page, I'll look into removing that link for nested fields.

since it should be the nested root itself, we must have that as an exact path somewhere?

There may not be an exact match. Consider a doubly nested field, foo.bar.baz where foo and bar are nested fields and baz is a regular subfield. baz will be the only field in the index pattern, and its path will be foo.bar. But foo will be the key in the flattened doc in Discover, so there won't be an exact match for it.

[Bargs]

Actually, the edit page includes popularity which does apply to the nested field in Discover since you can add it as a column in the doc table. So I think it makes sense to allow it.

[timroes]

So we would just need to make sure the edit page does not allow configuring a field formatter? Or rather that no field formatter works for nested fields, so we always have none assigned?

There may not be an exact match. Consider a doubly nested field, foo.bar.baz where foo and bar are nested fields and baz is a regular subfield. baz will be the only field in the index pattern, and its path will be foo.bar. But foo will be the key in the flattened doc in Discover, so there won't be an exact match for it.

I guess I am still a bit confused here :-) Looking at the way we this was shown earlier (#49842) wouldn't foo in that case be the field that will be shown in the column, because we basically "don't go deeper" than the first nested field and from then on just show the list of nested objects? So wouldn't we try to find a match for foo (or foo.bar in case we don't break on the first nested object), but never foo.bar.baz?

[Bargs]

Or rather that no field formatter works for nested fields, so we always have none assigned?

Yeah this is already the case now, the field formatter drop down is there but you can't change it to anything other than "Default". I think it's ok to leave it like that, since someone could technically create a field formatter for nested fields if they wanted to.

So wouldn't we try to find a match for foo (or foo.bar in case we don't break on the first nested object), but never foo.bar.baz?

Right, we'd search for foo because we look no deeper than the first level. The nested path metadata for the foo.bar.baz field will be foo.bar. So foo won't be identified as a nested field if we're only looking for exact matches. But if we look for partial matches we could get false positives on completely unrelated fields, for example if we had another top level field called foofoo it would be identified as a nested field.

[timroes]

I think I understand now, so this will always happen if we have the two nested fields directly below each other. Because saying we would have foo_nested.bar_object.baz_nested.ourfield and would try to look this, we would actually find the foo_nested.bar_object, which has the path metadata set to foo_nested? But as soon as the two nested fields are directly below each other, we're simply missing any field, that would have the link to the outer one?

(Extension with index pattern btw makes anyway sense for me :D)

[Bargs]

@cchaos what color would you recommend here?

[cchaos]

We're working on coming up with permanent field type icon/color combinations on the EUI side, but for now use colors[2]

[Bargs]

Tests are passing and I added a screenshot showing what it looks like now that EUI 18 is merged. @timroes do we want to put this is 7.6? If so could you give it a final review since you've already been looking at it?

[timroes]

@elasticmachine merge upstream

[timroes]

Code LGTM, tested on Chrome Linux behaves as expected. Waiting on green CI

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: b79d2e2

History

• 💔 Build #20348 failed 96537a1
• 💚 Build #20296 succeeded 3b7c31e
• 💔 Build #19974 failed 0aa9ede
• 💔 Build #18825 failed 7b6ce8d
• 💔 Build #18565 failed 64f7c37

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream