[Security Solution] Support snoozing in rules table

[maximpn]

Addresses: #147735

Summary

The PR adds an ability to set rule snoozing in the rules management table.

Screen recording:

Screen.Recording.2023-03-31.at.10.20.09.mov

Checklist

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

[elasticmachine]

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

[elasticmachine]

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

[banderror]

Hey @maximpn, thanks for working on this feature. I've done some local testing, and overall it looks fine, but there are a bunch of issues and bugs we need to fix.

Please review the issues below and let me know when they're fixed or if you'd like to chat about any of these. I'm going to review the diff later.

---

On page load, we do 2 calls to /internal/alerting/rules/_find. The first one returns empty results, the second call returns results as expected. What is the reason for this and can we call the endpoint just once?

---

Why does /internal/alerting/rules/_find return an array of actions?

---

When you click the Refresh button in the table, we only call /api/detection_engine/rules/_find (we refresh the rules) but not /internal/alerting/rules/_find (we don't refresh the snooze info). We need to do both to make sure the data we show in the table is up-to-date.

---

Not sure I see consistency in making /internal/alerting/rules/_find calls:

• After clicking Load Elastic prebuilt rules - YES
• After deleting 2 prebuilt rules and clicking Install 2 prebuilt rules - NO
• After selecting filters on the page - sometimes YES and sometimes NO
• After changing current page - sometimes YES and sometimes NO
• After changing page size - sometimes YES and sometimes NO

(YES mean we do call the /internal/alerting/rules/_find endpoint, NO means we don't make this call)

Given a rule with no actions. It is snoozed automatically on our side. When you edit this rule and add an action, and return to the Rules table, it continues to be shown as snoozed, although it just got unsnoozed on the BE side. You need to refresh the page to refresh its snooze info.

Same vice versa. Given a rule with some actions and frequency. It is unsnoozed automatically on our side. When you edit this rule and reset its frequency to Perform no actions, and return to the Rules table, it continues to be shown as unsnoozed, although it just got snoozed on the BE side. You need to refresh the page to refresh its snooze info.

---

There's an issue with z-index when you click remove all schedules.

[maximpn]

@banderror thank you for thorough testing 🙏 You managed to find some real problems related to cache invalidation and some problems are just side effects so let me break it down

On page load, we do 2 calls to /internal/alerting/rules/_find. The first one returns empty results, the second call returns results as expected. What is the reason for this and can we call the endpoint just once?

It was caused by using two useQuery hooks so the second hook tried to load rules snooze settings for the empty rules list while rules aren't loaded yet. It has been fixed.

When you click the Refresh button in the table, we only call /api/detection_engine/rules/_find (we refresh the rules) but not /internal/alerting/rules/_find (we don't refresh the snooze info). We need to do both to make sure the data we show in the table is up-to-date.

Rule snooze settings refetching upon clicking refresh button was missing and it has been fixed.

Not sure I see consistency in making /internal/alerting/rules/_find calls:
After clicking Load Elastic prebuilt rules - YES
After deleting 2 prebuilt rules and clicking Install 2 prebuilt rules - NO
After selecting filters on the page - sometimes YES and sometimes NO
After changing current page - sometimes YES and sometimes NO
After changing page size - sometimes YES and sometimes NO
(YES mean we do call the /internal/alerting/rules/_find endpoint, NO means we don't make this call)

It works as intended while cache invalidation after deleting 2 prebuilt rules and clicking Install 2 prebuilt rules was missed and it has been fixed. Default caching policy is applied to rules snooze settings data which 5 minutes and the same for the other data we fetch via React Query (besides rules as you can see here #153529). The other cases with sometimes reflect data reusing from the cache .

Given a rule with no actions. It is snoozed automatically on our side. When you edit this rule and add an action, and return to the Rules table, it continues to be shown as snoozed, although it just got unsnoozed on the BE side. You need to refresh the page to refresh its snooze info.

Same vice versa. Given a rule with some actions and frequency. It is unsnoozed automatically on our side. When you edit this rule and reset its frequency to Perform no actions, and return to the Rules table, it continues to be shown as unsnoozed, although it just got snoozed on the BE side. You need to refresh the page to refresh its snooze info.

Cache invalidation upon rule actions saving was missing and it has been fixed.

There's an issue with z-index when you click remove all schedules.

The problem is caused by fixing z-index issues related to the timeline, literally by this line of code. I've been working on resolving this issue. It can take some time and can be optionally addressed in a separate PR to avoid inflating the diff here.

UPDATE: There is a PR to address z-index issues which solves the current problem as well (see the screenshot below). I'll keep an eye on it.

[maximpn]

@elasticmachine merge upstream

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 52e347a

Failed CI Steps

• FTR Configs #54

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	3825	3828	+3

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
alerting	581	582	+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	9.1MB	9.1MB	+4.3KB
triggersActionsUi	1.4MB	1.4MB	+176.0B
total			+4.4KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
alerting	48.5KB	48.6KB	+94.0B

Unknown metric groups

API count

id	before	after	diff
alerting	602	603	+1

ESLint disabled line counts

id	before	after	diff
securitySolution	394	397	+3

Total ESLint disabled count

id	before	after	diff
securitySolution	474	477	+3

History

• 💔 Build #121343 failed 2c0b34b
• 💛 Build #120357 was flaky efeaa9d98c39b7d850834b713dcc5924cf2b2980
• 💔 Build #120304 failed 4f5061f59a99d90d48d9d4d01a27804108b5746c
• 💔 Build #120281 failed 81d02db80dbf0fc5b7bec8e8d23d1ef04b532049
• 💚 Build #119998 succeeded 9d985ceb86f2b9b185f6ae02c27f6b5f3867eddc

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

cc @maximpn