Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[8.12] [Security Solution] Exceptions flyout refreshes when it regain…
…s focus, causing configured fields to get cleared (#166550) (#172666) (#173131) # Backport This will backport the following commits from `main` to `8.12`: - [[Security Solution] Exceptions flyout refreshes when it regains focus, causing configured fields to get cleared (#166550) (#172666)](#172666) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Ievgen Sorokopud","email":"[email protected]"},"sourceCommit":{"committedDate":"2023-12-12T09:14:57Z","message":"[Security Solution] Exceptions flyout refreshes when it regains focus, causing configured fields to get cleared (#166550) (#172666)\n\n## Summary\r\n\r\nAddresses https://github.com/elastic/kibana/issues/166550\r\n\r\nThese changes fix the issue where user can experience data loss while\r\nadding rule exceptions.\r\n\r\nThe main issue is that we keep conditions state inside the child\r\ncomponent `ExceptionsConditions` which is rendered conditionally based\r\non `isLoading` flag. This flag changes when `useQuery` data gets stale\r\nand refetching is triggered. In this case we would remove\r\n`ExceptionsConditions` component while loading data and re-create it\r\nafter. Since conditions state stored inside `ExceptionsConditions` we\r\nwill lose it.\r\n\r\nThis is a quick fix to make sure our users are not frustrated. The state\r\nrefactoring will come separately in the next release when we are going\r\nto address the main issue\r\nhttps://github.com/elastic/security-team/issues/8197\r\n\r\nTo reproduce:\r\n1. Open \"add rule exception\" flyout\r\n2. Add exception conditions\r\n3. Wait for 5 minutes (to avoid waiting this long you can use [this\r\napproach](https://github.com/elastic/kibana/issues/166550#issuecomment-1802941467))\r\n4. Remove focus from the page (by switching to another app or navigating\r\nto a different tab in a browser)\r\n5. Focus on the page again\r\n\r\nWhen you are back to the page all exception conditions should still be\r\nthere.\r\n\r\n---------\r\n\r\nCo-authored-by: Vitalii Dmyterko <[email protected]>","sha":"a0631cf8bd0ce820c1a3768f02e8384afc922b27","branchLabelMapping":{"^v8.13.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team: SecuritySolution","backport:prev-minor","Team:Detection Engine","v8.13.0"],"number":172666,"url":"https://github.com/elastic/kibana/pull/172666","mergeCommit":{"message":"[Security Solution] Exceptions flyout refreshes when it regains focus, causing configured fields to get cleared (#166550) (#172666)\n\n## Summary\r\n\r\nAddresses https://github.com/elastic/kibana/issues/166550\r\n\r\nThese changes fix the issue where user can experience data loss while\r\nadding rule exceptions.\r\n\r\nThe main issue is that we keep conditions state inside the child\r\ncomponent `ExceptionsConditions` which is rendered conditionally based\r\non `isLoading` flag. This flag changes when `useQuery` data gets stale\r\nand refetching is triggered. In this case we would remove\r\n`ExceptionsConditions` component while loading data and re-create it\r\nafter. Since conditions state stored inside `ExceptionsConditions` we\r\nwill lose it.\r\n\r\nThis is a quick fix to make sure our users are not frustrated. The state\r\nrefactoring will come separately in the next release when we are going\r\nto address the main issue\r\nhttps://github.com/elastic/security-team/issues/8197\r\n\r\nTo reproduce:\r\n1. Open \"add rule exception\" flyout\r\n2. Add exception conditions\r\n3. Wait for 5 minutes (to avoid waiting this long you can use [this\r\napproach](https://github.com/elastic/kibana/issues/166550#issuecomment-1802941467))\r\n4. Remove focus from the page (by switching to another app or navigating\r\nto a different tab in a browser)\r\n5. Focus on the page again\r\n\r\nWhen you are back to the page all exception conditions should still be\r\nthere.\r\n\r\n---------\r\n\r\nCo-authored-by: Vitalii Dmyterko <[email protected]>","sha":"a0631cf8bd0ce820c1a3768f02e8384afc922b27"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.13.0","labelRegex":"^v8.13.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/172666","number":172666,"mergeCommit":{"message":"[Security Solution] Exceptions flyout refreshes when it regains focus, causing configured fields to get cleared (#166550) (#172666)\n\n## Summary\r\n\r\nAddresses https://github.com/elastic/kibana/issues/166550\r\n\r\nThese changes fix the issue where user can experience data loss while\r\nadding rule exceptions.\r\n\r\nThe main issue is that we keep conditions state inside the child\r\ncomponent `ExceptionsConditions` which is rendered conditionally based\r\non `isLoading` flag. This flag changes when `useQuery` data gets stale\r\nand refetching is triggered. In this case we would remove\r\n`ExceptionsConditions` component while loading data and re-create it\r\nafter. Since conditions state stored inside `ExceptionsConditions` we\r\nwill lose it.\r\n\r\nThis is a quick fix to make sure our users are not frustrated. The state\r\nrefactoring will come separately in the next release when we are going\r\nto address the main issue\r\nhttps://github.com/elastic/security-team/issues/8197\r\n\r\nTo reproduce:\r\n1. Open \"add rule exception\" flyout\r\n2. Add exception conditions\r\n3. Wait for 5 minutes (to avoid waiting this long you can use [this\r\napproach](https://github.com/elastic/kibana/issues/166550#issuecomment-1802941467))\r\n4. Remove focus from the page (by switching to another app or navigating\r\nto a different tab in a browser)\r\n5. Focus on the page again\r\n\r\nWhen you are back to the page all exception conditions should still be\r\nthere.\r\n\r\n---------\r\n\r\nCo-authored-by: Vitalii Dmyterko <[email protected]>","sha":"a0631cf8bd0ce820c1a3768f02e8384afc922b27"}}]}] BACKPORT--> Co-authored-by: Ievgen Sorokopud <[email protected]>
- Loading branch information