[Security Solution][Detection Engine] Fixes indicator matches mapping UI where invalid list values can cause overwrites of other values#89066
Conversation
…ake test writing more efficient
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
expected head sha didn’t match current head ref. |
rylnd
left a comment
There was a problem hiding this comment.
Tested this locally and the bugs look fixed! Thank you for the review notes, they were incredibly helpful ❤️ .
I had a few nits/hemming/hawing about the cypress stuff, but at the end of the day: it's more test coverage and it can be refactored later if need be. As long as CI is happy, this LGTM.
x-pack/plugins/security_solution/cypress/screens/create_new_rule.ts
Outdated
Show resolved
Hide resolved
| ); | ||
| }); | ||
|
|
||
| it('Does NOT show invalidation text on initial page load', () => { |
There was a problem hiding this comment.
Broad comment: these narrowly-focused tests are great for legibility and test isolation but likely terrible for CI speed. My preference for these types of tests is to walk through a particular user workflow, making assertions along the way until we get to a terminal point, e.g.:
- sign in, define rule, about rule, go back to define step and assert values are repopulated, create rule, assert rule created
This seems to be the predominant pattern in our cypress suite right now, so these new tests are a divergence from that. Neither's objectively correct, certainly, and I don't think these need to change, but I wanted to call out the difference. @MadameSheema may have a stronger opinion here 😉
...k/plugins/security_solution/cypress/integration/detection_rules/indicator_match_rule.spec.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/common/components/threat_match/helpers.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/common/components/threat_match/helpers.tsx
Outdated
Show resolved
Hide resolved
| * in the form of: | ||
| * flow(addIdToThreatMatchArray, myNewTransform)(rule) | ||
| * | ||
| * @param rule The rule to transform the output of |
There was a problem hiding this comment.
💯 on the JSDoc here, much appreciated 👍
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
… UI where invalid list values can cause overwrites of other values (elastic#89066) ## Summary This fixes the ReactJS keys to not use array indexes for the ReactJS keys which fixes elastic#84893 as well as a few other bugs that I will show below. The fix for the ReactJS keys is to add a unique id version 4 `uuid.v4()` to the incoming threat_mapping and the entities. On save out to elastic I remove the id. This is considered [better practices for ReactJS keys](https://reactjs.org/docs/lists-and-keys.html) Down the road we might augment the arrays to have that id information but for now I add them when we get the data and then remove them as we save the data. This PR also: * Fixes tech debt around the hooks to remove the disabling of the `react-hooks/exhaustive-deps` in a few areas * Fixes one React Hook misnamed that would not have triggered React linter rules (_useRuleAsyn) * Adds 23 new Cypress e2e tests * Adds a new pattern of dealing with on button clicks for the Cypress tests that are make it less flakey ```ts cy.get(`button[title="${indexField}"]`) .should('be.visible') .then(([e]) => e.click()); ``` * Adds several new utilities to Cypress for testing rows for indicator matches and other Cypress utils to improve velocity and ergonomics ```ts fillIndicatorMatchRow getDefineContinueButton getIndicatorInvalidationText getIndicatorIndexComboField getIndicatorDeleteButton getIndicatorOrButton getIndicatorAndButton ``` ## Bug 1 Deleting row 1 can cause row 2 to be cleared out or only partial data to stick around. Before:  After:  ## Bug 2 Deleting row 2 in the middle of 3 rows did not shift the value up correctly Before:  After:  ## Bug 3 When using OR with values it does not shift up correctly similar to AND Before:  After:  ### Checklist Delete any items that are not applicable to this PR. - [x] [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 - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)) - [ ] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
… UI where invalid list values can cause overwrites of other values (#89066) (#89817) ## Summary This fixes the ReactJS keys to not use array indexes for the ReactJS keys which fixes #84893 as well as a few other bugs that I will show below. The fix for the ReactJS keys is to add a unique id version 4 `uuid.v4()` to the incoming threat_mapping and the entities. On save out to elastic I remove the id. This is considered [better practices for ReactJS keys](https://reactjs.org/docs/lists-and-keys.html) Down the road we might augment the arrays to have that id information but for now I add them when we get the data and then remove them as we save the data. This PR also: * Fixes tech debt around the hooks to remove the disabling of the `react-hooks/exhaustive-deps` in a few areas * Fixes one React Hook misnamed that would not have triggered React linter rules (_useRuleAsyn) * Adds 23 new Cypress e2e tests * Adds a new pattern of dealing with on button clicks for the Cypress tests that are make it less flakey ```ts cy.get(`button[title="${indexField}"]`) .should('be.visible') .then(([e]) => e.click()); ``` * Adds several new utilities to Cypress for testing rows for indicator matches and other Cypress utils to improve velocity and ergonomics ```ts fillIndicatorMatchRow getDefineContinueButton getIndicatorInvalidationText getIndicatorIndexComboField getIndicatorDeleteButton getIndicatorOrButton getIndicatorAndButton ``` ## Bug 1 Deleting row 1 can cause row 2 to be cleared out or only partial data to stick around. Before:  After:  ## Bug 2 Deleting row 2 in the middle of 3 rows did not shift the value up correctly Before:  After:  ## Bug 3 When using OR with values it does not shift up correctly similar to AND Before:  After:  ### Checklist Delete any items that are not applicable to this PR. - [x] [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 - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)) - [ ] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
…nvalid values can cause overwrites of other values (#90634) ### Summary This PR is a follow-up to #89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder.
…nvalid values can cause overwrites of other values (elastic#90634) ### Summary This PR is a follow-up to elastic#89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder.
…nvalid values can cause overwrites of other values (elastic#90634) ### Summary This PR is a follow-up to elastic#89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder.
…nvalid values can cause overwrites of other values (#90634) (#92749) ### Summary This PR is a follow-up to #89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder. Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…nvalid values can cause overwrites of other values (#90634) (#92750) ### Summary This PR is a follow-up to #89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder. Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
This fixes the ReactJS keys to not use array indexes for the ReactJS keys which fixes #84893 as well as a few other bugs that I will show below. The fix for the ReactJS keys is to add a unique id version 4
uuid.v4()to the incoming threat_mapping and the entities. On save out to elastic I remove the id. This is considered better practices for ReactJS keysDown the road we might augment the arrays to have that id information but for now I add them when we get the data and then remove them as we save the data.
This PR also:
react-hooks/exhaustive-depsin a few areasBug 1
Deleting row 1 can cause row 2 to be cleared out or only partial data to stick around.
Before:

After:

Bug 2
Deleting row 2 in the middle of 3 rows did not shift the value up correctly
Before:

After:

Bug 3
When using OR with values it does not shift up correctly similar to AND
Before:

After:

Checklist
Delete any items that are not applicable to this PR.