[Mappings editor] Add support for constant_keyword field type

[alisonelizabeth]

Fixes #69751

Release note

The mappings editor in the Index Templates UI now supports configuring the constant_keyword field type.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[debadair]

Left a few suggestions. I didn't look closely at the other field types, so if they are inconsistent with existing UI text, I'd err on the side of consistency. (Though it looks like an editing pass of all of them might make sense at some point.)

[debadair]

I'd lead with a definition of the field type.

Suggested change

	defaultMessage="Constant keyword fields support the same queries and aggregations as {keyword} fields, but take advantage of the fact that all documents have the same value per index."
	defaultMessage="A special type of keyword field for fields that contain the same keyword across all documents in the index. Supports the same queries and aggregations as {keyword} fields."

[alisonelizabeth]

We've typically started all the descriptions with the name of the field type, so I've changed this to:

Constant keyword fields are a special type of keyword field for fields that contain the same keyword across all documents in the index. Supports the same queries and aggregations as {keyword} fields."

[alisonelizabeth]

Thanks @debadair for the copy review!

Left a few suggestions. I didn't look closely at the other field types, so if they are inconsistent with existing UI text, I'd err on the side of consistency. (Though it looks like an editing pass of all of them might make sense at some point.)

👍 The field type forms did go through copy review when they were initially added, but doesn't hurt to do a second pass at some point.

[alisonelizabeth]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[sebelga]

Great work @alisonelizabeth ! I tested locally and it works as expected. The issue I mentioned in #76671 around meta does not happen here.

But I would add an additional allowArray in the isJsonField validator (true by default to not create breaking change) that would return an error if an array is provided and the option is set to false.

[sebelga]

Same comment here as in #76671. No need anymore of the try/catch

serializer: (value: string) => {
  const parsed = JSON.parse(value);
  // If an empty object was passed, strip out this value entirely.
  if (!Object.keys(parsed).length) {
    return undefined;
  }
  return parsed;
},

[sebelga]

[EDIT]

The isue with the meta also occurs here as per my comment #76671 (comment)

It seems to occur when we use an index pattern that could also match other template, even with a totally unique field defined on the new template. And removing the meta fixes the ES error. I think that this should be investigated further.

[sebelga]

[EDIT 2]

Actually the index pattern does not have an effect. This request fails as well

[sebelga]

I'd like to investigate a bit further before approving as there is a very odd behavior. Maybe it is 100% on ES side, but I'd like to confirm this.

I'd like to investigate a bit further before approving as there is a very odd behavior. Maybe it is 100% on ES side, but I'd like to confirm this.

[alisonelizabeth]

@sebelga thanks for the review! I believe I addressed your feedback. Can you take another look when you get a chance?

The meta field only accepts strings as values. I believe that is why you were hitting the error.

Field metadata enforces at most 5 entries, that keys have a length that is less than or equal to 20, and that values are strings whose length is less than or equal to 50.

Do you think we should enforce these rules on the client? It is unfortunate that ES doesn't return a better error message.

[sebelga]

I will review it later today or tm morning.

The meta field only accepts strings as values. I believe that is why you were hitting the error.

I do think it'd be great to have a validator that makes sure that each value is a string. It is easy to add on our side and it could avoid a long debugging for the user to understand why his template is failing.

Maybe the reason is better explained by ES deeply nested in the error. I opened #77165 to improve the error message surfaced in the UI.

[alisonelizabeth]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 5c75148

Build metrics

‼️ unable to find a baseline build for [master@e5b302e]. Try merging the upstream branch and trying again.

History

• 💚 Build #74788 succeeded 22caf79
• 💚 Build #74199 succeeded f919daa
• 💚 Build #72862 succeeded d6c3dc6
• 💚 Build #72739 succeeded 7cc25b8
• 💚 Build #72358 succeeded ac11798

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

[sebelga]

Thanks for making the changes and adding the validation @alisonelizabeth ! Tested locally and works as expected 👍