[Response Ops] Handle unmapped fields in alert table sorting

[dplumlee]

Found in: https://github.com/elastic/sdh-security-team/issues/759 (internal)

Overview

When an unmapped field is selected from the field browser to add to the alerts table and then sorted on, the table breaks and hides all results including the sorting controls which causes a user to have to clear local storage in order to reset their table config and see results again. We need to either hide unmapped fields from the field browser or add in the necessary ES sorting params to the table sort calls to prevent error responses. The table should probably also not break entirely if a user finds themselves in this situation and a way to clear the sorting/pagination configuration could be provided.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[kqualters-elastic]

I think this fix is as simple as adding "unmapped_type": "keyword" for each field in the request:

    {
      "data_stream.type": {
        "order": "desc",
        "unmapped_type": "keyword"
      }
    }

[rylnd]

As mentioned in the linked SDH, a more specific workaround to clearing the full browser cache is to delete the detection-engine-alert-table-securitySolution-alerts-page-gridView localStorage key.

[111andre111]

Probably related: #83007 #154714 #171059

[e40pud]

Another SDH: https://github.com/elastic/sdh-security-team/issues/935

[kapral18]

Potentially another SDH: https://github.com/elastic/sdh-kibana/issues/5023

[rseldner]

Encountered this while helping some folks on 8.15.2 (no SDH to link). Found the lingering sort in the empty table's Inspector. Different browser, private session, or clearing the cache worked. Found this open issue after the fact so did not know we could just clear the detection-engine-alert-table-securitySolution-alerts-page-gridView key. This makes for some fun UX 😅

I see the PR is still pending. Might we add this to the known issues list? https://www.elastic.co/guide/en/security/current/release-notes-header-8.17.0.html