Disable selection of filter status 'All' on AddToCaseAction

[machadoum]

Closes #98742 "User not able to select "Closed" from drop-down on adding alert to existing case modal"

Summary

Hide status "all" and "closed" from the dropdown.

Expected Result
User should not be able to add an alert to a closed case

Before:

initial state

dropdown

After

Initial state

dropdown

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

[elasticmachine]

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

[elasticmachine]

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

[jonathan-buttner]

nice work! I tested and it's working great. Thanks for the fix!

[jonathan-buttner]

@machadoum any idea if the flaky test is related to the PR?

[cnasikas]

LGTM!

[machadoum]

@elasticmachine merge upstream

[machadoum]

@machadoum any idea if the flaky test is related to the PR?

@jonathan-buttner It doesn't look related because it failed before executing the code on my changes. The command that failed was "waitForAlertsPanelToBeLoaded". I did run cypress locally, and I could reproduce the flakiness both on my branch and on master. It seems that on some ocations the alert panel takes a very long time to load. Here you can see the console log in at the exact moment when the test fails:

     │ proc [cypress] GET /api/fleet/check-permissions 200 19.934 ms - -
     │ proc [cypress] POST /api/detection_engine/signals/search 200 41.550 ms - -
     │ proc [cypress] POST /api/detection_engine/signals/search 200 51.047 ms - -
     │ proc [cypress] GET /api/detection_engine/privileges 200 69.122 ms - -
     │ proc [cypress] GET /api/lists/privileges 200 110.861 ms - -
     │ proc [cypress] GET /api/ml/ml_capabilities 200 124.161 ms - -
     │ proc [cypress] POST /internal/bsearch 200 73.244 ms - -
     │ proc [cypress] GET /v1/pages/ChRDaHJvbWUvOTAuMC40NDMwLjIxMhIXCSY9dpwabVaEEgUNvYWDDxIFDZSQkvo=?alt=proto 200 26.190 ms - -
     │ proc [cypress] GET /api/detection_engine/index 200 29.554 ms - -
     │ proc [cypress] GET /api/lists/index 200 25.553 ms - -
     │ proc [cypress] POST /api/ml/jobs/jobs_summary 200 82.801 ms - -
     │ proc [cypress] GET /9007199254740991/bundles/plugin/data/kibana/data.chunk.6.js 304 26.732 ms - -
     │ proc [cypress] GET /api/ml/modules/recognize/apm-*-transaction*,auditbeat-*,endgame-*,filebeat-*,logs-*,packetbeat-*,winlogbeat-* 200 87.028 ms - -
     │ proc [cypress] GET /api/ml/modules/get_module/ 200 335.586 ms - -
     │ proc [cypress] POST /api/detection_engine/signals/search 200 20.392 ms - -
     │ proc [cypress] GET /v1/pages/ChRDaHJvbWUvOTAuMC40NDMwLjIxMhIzCTXHBmhl8lqwEgUNvYWDDxIFDa5VyV0SBQ1VIiXJEgUNkWGVThIFDQbtu_8SBQ2UkJL6?alt=proto 200 26.079 ms - -
     │ proc [cypress] POST /internal/bsearch 200 36.037 ms - -
     │ info [o.e.x.i.a.TransportPutLifecycleAction] [Pablos-MBP.home] updating index lifecycle policy [logs-endpoint.collection-diagnostic]
     │ proc [cypress] POST /api/fleet/epm/packages/_bulk 200 11337.906 ms - -
     │ proc [cypress] GET /v4/threatListUpdates:fetch?$req=Ch0KDGdvb2dsZWNocm9tZRINOTAuMC40NDMwLjIxMhopCAUQBBobCg0IBRAGGAEiAzAwMTABEJ-gCxoCGAWme-irIgQgASACKAEaKQgBEAQaGwoNCAEQBhgBIgMwMDEwARDt7QgaAhgFFrZRbyIEIAEgAigBGicIChAIGhkKDQgKEAgYASIDMDAxMAEQBhoCGAUrFDWWIgQgASACKAEaKQgHEAQaGwoNCAcQBhgBIgMwMDEwARCDqQkaAhgFh-OrySIEIAEgAigBGicIARAEGhkKDQgBEAYYASIDMDAxMAMQFBoCGAW0gZovIgQgASACKAMaKQgNEAQaGwoNCA0QBhgBIgMwMDEwARD8iAEaAhgFPEVFhiIEIAEgAigBGigIARAIGhoKDQgBEAgYASIDMDAxMAQQjiAaAhgF4RpJ0SIEIAEgAigEGicICRAEGhkKDQgJEAYYASIDMDAxMAYQAxoCGAX81dJ_IgQgASACKAYaKAgPEAQaGgoNCA8QBhgBIgMwMDEwARCBZhoCGAUIVVHjIgQgASACKAEaKAgIEAQaGgoNCAgQBhgBIgMwMDEwARCPDBoCGAVop6Q3IgQgASACKAEaJwgJEAQaGQoNCAkQBhgBIgMwMDEwARAfGgIYBZJ8iVciBCABIAIoARopCAMQBBobCg0IAxAGGAEiAzAwMTABEKDdCBoCGAU1OdFTIgQgASACKAEaKQgOEAQaGwoNCA4QBhgBIgMwMDEwARC8wgUaAhgFxzxyqiIEIAEgAigBGigIEBAEGhoKDQgQEAYYASIDMDAxMAEQ1woaAhgFpbXsCiIEIAEgAigBIgIIAQ==&$ct=application/x-protobuf&key=AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw 200 60.237 ms - -
     │ proc [cypress] POST /api/ui_counters/_report 200 661.319 ms - -```

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 7747a1c
• 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
cases	494.0KB	494.3KB	+302.0B
securitySolution	6.7MB	6.7MB	+16.0B
total			+318.0B

Unknown metric groups

References to deprecated APIs

id	before	after	diff
canvas	29	25	-4
crossClusterReplication	8	6	-2
fleet	4	2	-2
globalSearch	4	2	-2
indexManagement	12	7	-5
infra	5	3	-2
licensing	18	15	-3
monitoring	109	56	-53
total			-73

History

• 💛 Build #125581 was flaky 0578154
• 💚 Build #125508 succeeded 80cb340
• 💔 Build #125495 failed e28ac78affed97eeda99bfc6be14a0e9facec2d8
• 💚 Build #125312 succeeded d4004524a374052ebfac3be9e10758cf5de57cff
• 💚 Build #125254 succeeded 2f8b3ada40913621d7d1b0292dc165e89f82071d

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

cc @machadoum

[jonathan-buttner]

@machadoum any idea if the flaky test is related to the PR?

@jonathan-buttner It doesn't look related because it failed before executing the code on my changes. The command that failed was "waitForAlertsPanelToBeLoaded". I did run cypress locally, and I could reproduce the flakiness both on my branch and on master. It seems that on some ocations the alert panel takes a very long time to load. Here you can see the console log in at the exact moment when the test fails:

Thanks for looking! Sounds good, feel free to merge, we can address the flaky test at a different time 👍