Closed sebelga closed 2 years ago
Pinging @elastic/kibana-app-services (Team:AppServices)
Pinging @elastic/es-ui (Team:Elasticsearch UI)
All that sounds reasonable for me, I guess my only question would be: should the parent
flag also be written for non runtime fields object fields, or will it be a specific thing for runtime fields?
All that sounds reasonable for me, I guess my only question would be: should the parent flag also be written for non runtime fields object fields, or will it be a specific thing for runtime fields?
Any field could potentially define it but for the time being it would only be set when creating runtime fields.
:warning: [EDIT]: I've created https://github.com/elastic/kibana/discussions/99462 to discuss this proposal. Let's use that discussion to raise concerns and suggest alternatives/modifications. Once we have committed on the changed required I will update the description of the issue.
Problem
Object runtime fields give the user the possibility to declare multiple sub fields inside a parent object through a script. For that the user will
emit
multiple value from the painless script as a set of key/value pairs. The problem is: this single runtime field, once saved in the Kibana index pattern, will appear as one field and none of the sub fields will be exposed. When an app (Lens, Discover) will ask for the list of fields on the index pattern it will then receive this top object runtime field and none of the associated sub fields.Proposal
I suggest the following:
New
subFields
propThe field editor returns a new optional
subFields
property on the runtime field (following the naming convention in place for concrete fields)Add a
parent
(optional) parameter to index pattern field definitionThis will allow us the normal CRUD operation like other runtime fields:
List: We will return only the leaf object and not the parent object runtime field with the
script
(we follow the same behaviour that Kibana does today forobject
andnested
fields). For that we need to:Create: To create subFields we need to update addRuntimeField() to not only create the parent runtime field object but also all of its subFields
Edit: When editing an leaf object (e.g.
myRuntimeObject.foo
) we will:parent
which is also a runtime field (with a runtimeField definition + ascript
)script
section, just like any concrete field (with custom label, format, priority). We would add an info callout saying that this field comes from an object runtime field with a link to edit the parent object field.Delete: To delete a leaf object field we would open a modal saying that this field has been generated by an object runtime field script and that the user needs to modify the parent's
script
. We would add a button for the user to open the field editor and edit the script in order to remove the child field.Support format for sub fields
We also need to update the logic to add the
format
definition for each subField to the index pattern attributes (here: index pattern field editor)cc @mattkime @stacey-gammon