[Security Solution] Rules table shows stale rules data on enabled/disabled filter change #151151
Closed
1 task
Assignees
Labels
8.7 candidate
bug
Fixes for quality problems that affect the customer experience
Feature:Rule Management
Security Solution Detection Rule Management area
fixed
impact:high
Addressing this issue will have a high level of impact on the quality/strength of our product.
QA:Validated
Issue has been validated by QA
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
v8.7.0
Comments
xcrzx
added
bug
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
xcrzx
added
the
impact:high
1 task
maximpn
added a commit
that referenced
this issue
Feb 21, 2023
…le (#151284) **Addresses:** #151151 ## Summary It fixes rules filtering after enabling or disabling a rule. ### Details The problem is caused by improper cache invalidation. Rules cache used to be modified upon enabling or disabling one or more rules but it started causing troubles after introduction a filter by enabled or disabled state. Cached rules modification is is complex and bug prone especially taking into account it will need to mirror backend logic and further plans on extending rule filers. So the simplest solution is invalidation of the whole rules cache. Though it may also lead to unfriendly UX when disabled or enabled rules "jump" in the table. The best approach is marking find rule request cached data as stale so data is refetched each time use changes filter state, sort by field or use pagination. **Before:** https://user-images.githubusercontent.com/1938181/218776621-f8903a88-1685-4a2c-9074-02fac0623dc4.mov **After:** https://user-images.githubusercontent.com/3775283/219630525-af109575-3a01-4988-bb6b-690473d33b80.mov ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
maximpn
added a commit
to maximpn/kibana
that referenced
this issue
Feb 22, 2023
…le (elastic#151284) **Addresses:** elastic#151151 ## Summary It fixes rules filtering after enabling or disabling a rule. ### Details The problem is caused by improper cache invalidation. Rules cache used to be modified upon enabling or disabling one or more rules but it started causing troubles after introduction a filter by enabled or disabled state. Cached rules modification is is complex and bug prone especially taking into account it will need to mirror backend logic and further plans on extending rule filers. So the simplest solution is invalidation of the whole rules cache. Though it may also lead to unfriendly UX when disabled or enabled rules "jump" in the table. The best approach is marking find rule request cached data as stale so data is refetched each time use changes filter state, sort by field or use pagination. **Before:** https://user-images.githubusercontent.com/1938181/218776621-f8903a88-1685-4a2c-9074-02fac0623dc4.mov **After:** https://user-images.githubusercontent.com/3775283/219630525-af109575-3a01-4988-bb6b-690473d33b80.mov ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 9683beb)
banderror
added
Feature:Rule Management
|
Fix not available on BC3. Pending to be validated on BC4. |
maximpn
referenced
this issue
Feb 24, 2023
…g a rule (#151284) (#151861) # Backport This will backport the following commits from `main` to `8.7`: - [[Security Solution] Fix rules filtering after enabling/disabling a rule (#151284)](#151284) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Maxim Palenov","email":"maxim.palenov@elastic.co"},"sourceCommit":{"committedDate":"2023-02-21T09:43:25Z","message":"[Security Solution] Fix rules filtering after enabling/disabling a rule (#151284)\n\n**Addresses:** https://github.com/elastic/kibana/issues/151151\r\n\r\n## Summary\r\n\r\nIt fixes rules filtering after enabling or disabling a rule.\r\n\r\n### Details\r\n\r\nThe problem is caused by improper cache invalidation. Rules cache used to be modified upon enabling or disabling one or more rules but it started causing troubles after introduction a filter by enabled or disabled state. Cached rules modification is is complex and bug prone especially taking into account it will need to mirror backend logic and further plans on extending rule filers. So the simplest solution is invalidation of the whole rules cache. Though it may also lead to unfriendly UX when disabled or enabled rules \"jump\" in the table. The best approach is marking find rule request cached data as stale so data is refetched each time use changes filter state, sort by field or use pagination.\r\n\r\n**Before:**\r\n\r\nhttps://user-images.githubusercontent.com/1938181/218776621-f8903a88-1685-4a2c-9074-02fac0623dc4.mov\r\n\r\n**After:**\r\n\r\nhttps://user-images.githubusercontent.com/3775283/219630525-af109575-3a01-4988-bb6b-690473d33b80.mov\r\n\r\n\r\n### Checklist\r\n\r\n- [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios","sha":"9683beba6af5f78fa88350aa5bcab95d767cd763","branchLabelMapping":{"^v8.8.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rules","v8.7.0","v8.8.0"],"number":151284,"url":"https://github.com/elastic/kibana/pull/151284","mergeCommit":{"message":"[Security Solution] Fix rules filtering after enabling/disabling a rule (#151284)\n\n**Addresses:** https://github.com/elastic/kibana/issues/151151\r\n\r\n## Summary\r\n\r\nIt fixes rules filtering after enabling or disabling a rule.\r\n\r\n### Details\r\n\r\nThe problem is caused by improper cache invalidation. Rules cache used to be modified upon enabling or disabling one or more rules but it started causing troubles after introduction a filter by enabled or disabled state. Cached rules modification is is complex and bug prone especially taking into account it will need to mirror backend logic and further plans on extending rule filers. So the simplest solution is invalidation of the whole rules cache. Though it may also lead to unfriendly UX when disabled or enabled rules \"jump\" in the table. The best approach is marking find rule request cached data as stale so data is refetched each time use changes filter state, sort by field or use pagination.\r\n\r\n**Before:**\r\n\r\nhttps://user-images.githubusercontent.com/1938181/218776621-f8903a88-1685-4a2c-9074-02fac0623dc4.mov\r\n\r\n**After:**\r\n\r\nhttps://user-images.githubusercontent.com/3775283/219630525-af109575-3a01-4988-bb6b-690473d33b80.mov\r\n\r\n\r\n### Checklist\r\n\r\n- [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios","sha":"9683beba6af5f78fa88350aa5bcab95d767cd763"}},"sourceBranch":"main","suggestedTargetBranches":["8.7"],"targetPullRequestStates":[{"branch":"8.7","label":"v8.7.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.8.0","labelRegex":"^v8.8.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/151284","number":151284,"mergeCommit":{"message":"[Security Solution] Fix rules filtering after enabling/disabling a rule (#151284)\n\n**Addresses:** https://github.com/elastic/kibana/issues/151151\r\n\r\n## Summary\r\n\r\nIt fixes rules filtering after enabling or disabling a rule.\r\n\r\n### Details\r\n\r\nThe problem is caused by improper cache invalidation. Rules cache used to be modified upon enabling or disabling one or more rules but it started causing troubles after introduction a filter by enabled or disabled state. Cached rules modification is is complex and bug prone especially taking into account it will need to mirror backend logic and further plans on extending rule filers. So the simplest solution is invalidation of the whole rules cache. Though it may also lead to unfriendly UX when disabled or enabled rules \"jump\" in the table. The best approach is marking find rule request cached data as stale so data is refetched each time use changes filter state, sort by field or use pagination.\r\n\r\n**Before:**\r\n\r\nhttps://user-images.githubusercontent.com/1938181/218776621-f8903a88-1685-4a2c-9074-02fac0623dc4.mov\r\n\r\n**After:**\r\n\r\nhttps://user-images.githubusercontent.com/3775283/219630525-af109575-3a01-4988-bb6b-690473d33b80.mov\r\n\r\n\r\n### Checklist\r\n\r\n- [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios","sha":"9683beba6af5f78fa88350aa5bcab95d767cd763"}}]}] BACKPORT--> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
|
@MadameSheema We finally merged the backport and the fix will be available in BC4. |
|
We have validated this issue on 8.7.0 BC4 build and observed that issue is not occurring, It is Fixed. ✔️ Please find the below Testing Details: Build info Screen-Recording Rules.-.Kibana.Mozilla.Firefox.2023-03-02.14-27-55.mp4Hence, We are Closing this issue and marking it as QA Validated!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
Screen.Recording.2023-02-14.at.16.04.27.mov
Expected result
Only enabled rules displayed on the table
Actual result
Disabled rules displayed on the table as well as enabled
The text was updated successfully, but these errors were encountered: