[Security Solution] Changes coverage overview subtechnique display to base off active filters

[dplumlee]

Fixes: #170945

Summary

Changes our sub-technique display logic to no longer just represent the enabled rules, but all rules that fall under the current page filters - similar to our tile coloring logic.

Screenshots

When only enabled filter is active

When enabled and disabled filters are active

Checklist

Delete any items that are not applicable to this PR.

• 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)

[elasticmachine]

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

[dplumlee]

@elasticmachine merge upstream

[dplumlee]

@elasticmachine merge upstream

[dplumlee]

@elasticmachine merge upstream

[banderror]

Tested the PR locally and checked the use case from the #170945 ticket. All worked as expected.

Reviewed the changes and left a few comments that shouldn't block the PR from merging. Thank you @dplumlee for the quick fix!

[banderror]

I think these tests need some refactoring later. The functions that create mocks are not parameterized and return implicit data. This means that we set the frontend-side CoverageOverview model in these tests implicitly, while the assertions are explicit. It's hard to read such tests because you always need to jump to the mock functions implementation and compare it with the assertions. Also, it makes the tests setup too rigid and we're probably missing a few tests cases because of that. For example, the mock data makes the same rule both enabled and disabled at the same time, which is 1) incorrect and 2) we need to test more than one rule mapped to the same technique through 2 or more tactics, and also test different combinations of these rules being enabled and disabled.

I'm not suggesting to address this in this PR, but this is something to work on later when we get back to working on the next milestone for the Coverage epic.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 05b4fbc

Failed CI Steps

• FTR Configs #67
• Security Solution Cypress Tests #11

Test Failures

• [job] [logs] Security Solution Cypress Tests #11 / Use Value list in exception entry Should use value list in exception entry, and validate deleting value list prompt Should use value list in exception entry, and validate deleting value list prompt

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	4669	4670	+1

Async chunks

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

id	before	after	diff
securitySolution	13.0MB	13.0MB	+163.0B

History

• 💛 Build #175441 was flaky 45f45842bf938ad6abf32aabf78403297bbc453e
• 💔 Build #175423 failed ac3fffd9806dbe1581e4d3d06da128c1adae625d
• 💚 Build #175156 succeeded d26f6624112109a88ed0cbf7647dac7bd2162109
• 💔 Build #175112 failed 29b7d0a
• 💚 Build #174779 succeeded e6d43c0

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

cc @dplumlee

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.11

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

[ghost]

Hi @dplumlee

we have validated this issue and found the issue to be fixed on 8.11.2 ✔️ .

Now rule details are showing as per the current page filter set.

Build details:

Version: 8.11.2
Commit: 92746356b61c3e3ac62b6d7045727f8d737fa4b5
Build:68299

Observations:

• Page Filter : Only Enabled : O/P : Only Enabled rules details are showing

test.mp4

• Page Filter: Only Disabled : O/P : Only Disabled rules details are showing

only_disabled.mp4

• Page Filter : Enabled + Disabled : O/P : Both Enabled and Disabled rules details are showing

both.mp4

Hence we are adding "QA:Validated" tag to it.

thanks !!