[Security Solution] Disable filter cellActions for unmapped fields on Alerts table

[semd]

Summary

bug: https://github.com/elastic/sdh-security-team/issues/549
epic: #144943

Filter actions are not working properly on the Alerts page for fields that are not mapped in the alert's index.

This problem was not been introduced by the cell-actions package, it was carried with the migration from SecuritySolution hoverActions. A fix for the cell-actions package would be the following.

Fix description

This fix will need to be done after we adopt FieldSpec (#150347 (comment)) for the field type of the actions, we'll be able to check the isMapped flag in the action's isCompatible function to decide if the FilterIn/Out actions should be displayed or hide.

To define the value of the isMapped prop we'll have to do a lookup of the indexes array of the field in the browserFields data, and check if the alert's index is present.

---

Update
The bug happens when a field is not mapped on the alert's index but it is mapped on another index in the security data view.
The sorcerer API returns that the field is mapped but fails when we search on the Alerts index.

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[machadoum]

auto-closed by mistake

[machadoum]

The team discussed this bug, and we think that it isn't a CellActions bug but a data view/sorcerer + Alerts table bug.

The bug happens when a field is not mapped on the alert's index but it is mapped on another index in the security data view.
The sorcerer API returns that the field is mapped but fails when we search on the Alerts index.

It happens because the alerts table uses a security data view but only searches on the alert's index. So the root problem is how Dataview is configured for the Alerts table.

This bug isn't something exclusive to CellActions. For example, if the user tries to sort a column that is not mapped on the Alert index, an error happens, and after a refresh, the alerts table doesn't show up anymore.

Jul-03-2023.11-51-45.mov

[stefnestor]

Related: #136351 , #166168 , #144943

[111andre111]

Probably another related issue: #170167 #171059

[111andre111]

related: #171059

[elasticmachine]

Pinging @elastic/security-detection-engine (Team:Detection Engine)

[lgestc]

After looking at this for a few days, I an conviced that the data view selected in the sourcerer does not impact the pattern list used to retrieve the browser fields for the alerts table.

New data view created

After forcing the data view to be the new one in security solution codebase, I am still getting over 2k fields:

Regardless of the new dataViewId passed in here: /home/luke/projects/kibana/src/plugins/data_views/common/data_views/data_views.ts ->

the title (aka. the index pattern string) here:

remains the same, which results in all the security solution fields rendered as compatible with the alerts table view.

After the pattern is explitly set to .alerts-security.alerts-default, the field count looks correctly:

Draft pr where I set the pattern explicitly when the dataViewId is alerts:
#181540

[lgestc]

on hold until the we refactor data view selection