[Security Solution][Exceptions] Allows bulk close on exception to close acknowledged alerts

[dplumlee]

Summary

Up till now, when the bulk close checkbox is selected on a created or updated rule exception, it just closes any open alerts that meet the criteria. This updates the status filters we use for the POST queries to include both acknowledged and in-progress(for backwards compatibility) so all alerts that aren't already closed will be on submit.

Important Note

This functionality is currently broken on pre-7.15 endpoint alerts and a related ticket has been opened. Once that logic is fixed, it should automatically work with these changes and fix the issue for endpoint alerts as well.

Checklist

Delete any items that are not applicable to this PR.

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 104ac8f
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	6.5MB	6.5MB	+635.0B

Unknown metric groups

References to deprecated APIs

id	before	after	diff
securitySolution	782	788	+6

History

• 💔 Build #148737 failed 98b252b

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

cc @dplumlee

[FrankHassanabad]

fwiw, the meta field has a legacy behind it where at one point we found we were accidentally broken when it wasn't there and we had to ship and add it.

I don't know if that is still true today and that's why we still have to use it or if it's for a particular UI usage or other reasoning such as, "All the rest have them so I thought it was for a good reason?"

[dplumlee]

I was talking to @spong a couple days ago about this and it seemed as if we only use it nowadays to populate the global kql query bar and as these functions are used currently as a "straight to ES query" helper functions it doesn't seem to cause any issues, but any thoughts appreciated

[FrankHassanabad]

I think it's fine as is for now. We might revisit all of them later.

[FrankHassanabad]

I think you could write a unit test for this one like the other one right? I would add one for this if it is the future?

The comment at the top looks odd with the TODO, isn't this the one that shouldn't be removed?

[dplumlee]

No the rule registry ones will eventually be removed in favor of the regular functions once the aliases are finalized so I've just been writing tests for the ones that will stay. The functions are identical other than the placeholder alias names so I figured it wouldn't be an issue short term since they'll be removed within another couple weeks likely

[FrankHassanabad]

LGTM,

• I opened dev tools and ran some queries that were similar to the should below in this PR to make sure it looked okay.

DELETE delme-frank-1
PUT delme-frank-1
PUT delme-frank-1
{
  "mappings": {
      "properties": {
        "signal": {
          "properties": {
            "status": {
              "type": "keyword"
            }
          }
        },
        "@timestamp": {
          "type": "keyword"
        }
      }
  }
}

PUT delme-frank-1/_doc/1
{
  "@timestamp": "2021-08-26T18:24:20.047Z"
}

PUT delme-frank-1/_doc/2
{
  "signal.status": "open"
}

GET delme-frank-1/_search

GET delme-frank-1/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "term": {
            "signal.status": "open"
          }
        },
        {
          "term": {
            "signal.status": "acknowledged"
          }
        },
        {
          "term": {
            "signal.status": "in-progress"
          }
        }
      ]
    }
  }
}

Got back:

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    },
    "max_score" : 0.2876821,
    "hits" : [
      {
        "_index" : "delme-frank-1",
        "_id" : "2",
        "_score" : 0.2876821,
        "_source" : {
          "signal.status" : "open"
        }
      }
    ]
  }
}

So I think this works well.

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	7.15
✅	7.x

The backport PRs will be merged automatically after passing CI.