[Security Solution] Incorrect icon is displaying for numeric type under Required fields

[ghost]

Describe the bug
Incorrect icon is displaying for numeric type under Required fields

Build info

Version: 8.3.0 Branch
Commit: fe0166d7991c7220bd4321defcbaa5c1e614dc90  

preconditions

1. Kibana should be up and running

Steps to Reproduce

1. Navigate to Rules page under security

2. Import the below rule that contains the required fields with numeric type
   rules_export (2).zip

3. After import the rule navigate to rule details page

4. Observe that incorrect icon is displaying for numeric type under "Required fields"

Actual Result
Incorrect icon is displaying for numeric type under "Required fields"

Expected Result
Correct icon say # should be displayed for numeric type under "Required fields"

What's Working

Screenshot

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[spong]

Currently we're using the re-usable FieldIcon component for displaying these field types. This is the same component used by Discover so we should expect parity with that UI, but let me check and see what the FieldsBrowser component referenced in the description is using and maybe we can leverage that.

Either way, we should be able to add float (and any other missing field types) to the FieldIcon component here:

kibana/packages/kbn-react-field/src/field_icon/field_icon.tsx

Lines 39 to 61 in 76e77c2

	export const typeToEuiIconMap: Partial<Record<string, EuiTokenProps>> = {
	boolean: { iconType: 'tokenBoolean' },
	// icon for an index pattern mapping conflict in discover
	conflict: { iconType: 'alert', color: 'euiColorVis9', shape: 'square' },
	date: { iconType: 'tokenDate' },
	date_range: { iconType: 'tokenDate' },
	geo_point: { iconType: 'tokenGeo' },
	geo_shape: { iconType: 'tokenGeo' },
	ip: { iconType: 'tokenIP' },
	ip_range: { iconType: 'tokenIP' },
	match_only_text: { iconType: 'tokenString' },
	// is a plugin's data type https://www.elastic.co/guide/en/elasticsearch/plugins/current/mapper-murmur3-usage.html
	murmur3: { iconType: 'tokenSearchType' },
	number: { iconType: 'tokenNumber' },
	number_range: { iconType: 'tokenNumber' },
	histogram: { iconType: 'tokenHistogram' },
	_source: { iconType: 'editorCodeBlock', color: 'gray' },
	string: { iconType: 'tokenString' },
	text: { iconType: 'tokenString' },
	keyword: { iconType: 'tokenKeyword' },
	nested: { iconType: 'tokenNested' },
	version: { iconType: 'tokenTag' },
	};

[spong]

So there's a few different behaviors here depending on if you look at Discover, the Security Solution Fields Browser, or the Security Solution Event Details Flyout.

Discover, the Event Details Flyout, and the current Required Fields implementation are all using the FieldIcon component as mentioned above, with the key difference being that the Required Fields implementation is using ES_FIELD_TYPES vs KBN_FIELD_TYPES, as this is what is provided to us from the Rule SO. It's this mis-match between the two that causes this missing icon issue.

After some searching, it seems there's a conversion utility castEsToKbnFieldTypeName over in the kbn-field-types package that we can use to get a reliable kbnFieldType to pass on to the FieldIcon. And since the FieldIcon component is going to use that kbn type as the hover text, we'll need to override the label with the actual es type they need to have in their mapping so e.g. risk.score shows as float instead of number.

Without label override:

With label override:

[spong]

Platform fix has been merged as of #133690, however still waiting on actual fix in #133050 to merge before this can be re-tested/closed.

[banderror]

Fixed in #133050. Will be available in the next 8.3.0 BC.

[ghost]

Hi @banderror ,

We have validated above issue on 8.3.0 BC4 and observed that issue is Fixed 🟢

Please find the below testing details

Build info:

Version : 8.3.0 BC4
Build : 53413
Commit : 875ea184462f73a04410981ac9eaf799db28b4f0

Screenshots/Screencast:

Hence, We are closing this issue and marking this as QA Validated.

Thanks!