[Security Solution] Allow rewriting rule create props in Cypress tests #153474
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maximpn
added
enhancement
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
michaelolo24
approved these changes
Mar 23, 2023
stephmilovic
approved these changes
Mar 23, 2023
maximpn
force-pushed
the
rule-creator-prop-rewrites
branch
from
defdc3d
to
bcb9359
Compare
…-ref HEAD~1..HEAD --fix'
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @maximpn |
banderror
added
refactoring
test-coverage
banderror
changed the title
|
@maximpn please be mindful about backports 🙏 |
banderror
changed the title
banderror
added
test
test_ui_functional
technical debt
dhurley14
approved these changes
Mar 24, 2023
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
maximpn
added a commit
to maximpn/kibana
that referenced
this pull request
Apr 4, 2023
elastic#153474) **Relates to:** elastic#150553 ## Summary This PR is based on the review comments in elastic#150553. It allows to rewrite rule create properties. ## Details Rule create properties are returned by helper functions like `getNewRule()`, `getNewThresholdRule()` and so on. So instead of `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` it allows to use a concise and a much more readable structure `createRule(getNewRule({ index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' ))`. ## Possible improvements The PR doesn't implement deep / nested fields merge. High level fields completely rewrite default values. Deep merge would allow to extend defaults with the provided rewrites. For example, overriding nested properties become tiresome quickly, as shown in the following code snippet: ```ts const rule = { ...getNewTermsRule(), rule_id: 'new_rule_id', runsEvery: { interval: '1', ...getNewTermsRule().runsEvery, }, }; ``` If we implement deep merge, the readability could be greatly improved: ```ts const rule = getNewTermsRule({ rule_id: 'new_rule_id', runsEvery: { interval: '1', }, }); ``` While it looks as a good idea we should take into consideration the fact that complete rewriting of default values can be a desired behavior. Engineers could tend to switch to `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` to overcome deep merge. So it should be analysed carefully before implementing it. (cherry picked from commit ca696ac) # Conflicts: # x-pack/plugins/security_solution/cypress/e2e/detection_alerts/alerts_charts.cy.ts # x-pack/plugins/security_solution/cypress/e2e/detection_alerts/detection_page_filters.cy.ts # x-pack/plugins/security_solution/cypress/e2e/exceptions/add_edit_flyout/flyout_validation.cy.ts
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
maximpn
added a commit
that referenced
this pull request
Apr 4, 2023
…s tests (#153474) (#154332) # Backport This will backport the following commits from `main` to `8.7`: - [[Security Solution] Allow rewriting rule create props in Cypress tests (#153474)](#153474) <!--- 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-03-27T09:08:38Z","message":"[Security Solution] Allow rewriting rule create props in Cypress tests (#153474)\n\n**Relates to:** #150553 Summary\r\n\r\nThis PR is based on the review comments in #150553. It allows to rewrite rule create properties.\r\n\r\n## Details\r\n\r\nRule create properties are returned by helper functions like `getNewRule()`, `getNewThresholdRule()` and so on. So instead of `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` it allows to use a concise and a much more readable structure `createRule(getNewRule({ index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' ))`.\r\n\r\n## Possible improvements\r\n\r\nThe PR doesn't implement deep / nested fields merge. High level fields completely rewrite default values. Deep merge would allow to extend defaults with the provided rewrites. For example, overriding nested properties become tiresome quickly, as shown in the following code snippet:\r\n\r\n```ts\r\nconst rule = {\r\n ...getNewTermsRule(),\r\n rule_id: 'new_rule_id',\r\n runsEvery: {\r\n interval: '1',\r\n ...getNewTermsRule().runsEvery,\r\n },\r\n};\r\n```\r\n\r\nIf we implement deep merge, the readability could be greatly improved:\r\n\r\n```ts\r\nconst rule = getNewTermsRule({\r\n rule_id: 'new_rule_id',\r\n runsEvery: {\r\n interval: '1',\r\n },\r\n});\r\n```\r\n\r\nWhile it looks as a good idea we should take into consideration the fact that complete rewriting of default values can be a desired behavior. Engineers could tend to switch to `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` to overcome deep merge. So it should be analysed carefully before implementing it.","sha":"ca696ac50c0591acf6723e130d2f9278c2d6ef65","branchLabelMapping":{"^v8.8.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["test","refactoring","test_ui_functional","technical debt","release_note:skip","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rules","backport:prev-minor","v8.8.0"],"number":153474,"url":"#153474 Solution] Allow rewriting rule create props in Cypress tests (#153474)\n\n**Relates to:** #150553 Summary\r\n\r\nThis PR is based on the review comments in #150553. It allows to rewrite rule create properties.\r\n\r\n## Details\r\n\r\nRule create properties are returned by helper functions like `getNewRule()`, `getNewThresholdRule()` and so on. So instead of `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` it allows to use a concise and a much more readable structure `createRule(getNewRule({ index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' ))`.\r\n\r\n## Possible improvements\r\n\r\nThe PR doesn't implement deep / nested fields merge. High level fields completely rewrite default values. Deep merge would allow to extend defaults with the provided rewrites. For example, overriding nested properties become tiresome quickly, as shown in the following code snippet:\r\n\r\n```ts\r\nconst rule = {\r\n ...getNewTermsRule(),\r\n rule_id: 'new_rule_id',\r\n runsEvery: {\r\n interval: '1',\r\n ...getNewTermsRule().runsEvery,\r\n },\r\n};\r\n```\r\n\r\nIf we implement deep merge, the readability could be greatly improved:\r\n\r\n```ts\r\nconst rule = getNewTermsRule({\r\n rule_id: 'new_rule_id',\r\n runsEvery: {\r\n interval: '1',\r\n },\r\n});\r\n```\r\n\r\nWhile it looks as a good idea we should take into consideration the fact that complete rewriting of default values can be a desired behavior. Engineers could tend to switch to `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` to overcome deep merge. So it should be analysed carefully before implementing it.","sha":"ca696ac50c0591acf6723e130d2f9278c2d6ef65"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.8.0","labelRegex":"^v8.8.0$","isSourceBranch":true,"state":"MERGED","url":"#153474 Solution] Allow rewriting rule create props in Cypress tests (#153474)\n\n**Relates to:** #150553 Summary\r\n\r\nThis PR is based on the review comments in #150553. It allows to rewrite rule create properties.\r\n\r\n## Details\r\n\r\nRule create properties are returned by helper functions like `getNewRule()`, `getNewThresholdRule()` and so on. So instead of `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` it allows to use a concise and a much more readable structure `createRule(getNewRule({ index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' ))`.\r\n\r\n## Possible improvements\r\n\r\nThe PR doesn't implement deep / nested fields merge. High level fields completely rewrite default values. Deep merge would allow to extend defaults with the provided rewrites. For example, overriding nested properties become tiresome quickly, as shown in the following code snippet:\r\n\r\n```ts\r\nconst rule = {\r\n ...getNewTermsRule(),\r\n rule_id: 'new_rule_id',\r\n runsEvery: {\r\n interval: '1',\r\n ...getNewTermsRule().runsEvery,\r\n },\r\n};\r\n```\r\n\r\nIf we implement deep merge, the readability could be greatly improved:\r\n\r\n```ts\r\nconst rule = getNewTermsRule({\r\n rule_id: 'new_rule_id',\r\n runsEvery: {\r\n interval: '1',\r\n },\r\n});\r\n```\r\n\r\nWhile it looks as a good idea we should take into consideration the fact that complete rewriting of default values can be a desired behavior. Engineers could tend to switch to `createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })` to overcome deep merge. So it should be analysed carefully before implementing it.","sha":"ca696ac50c0591acf6723e130d2f9278c2d6ef65"}}]}] BACKPORT-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates to: #150553
Summary
This PR is based on the review comments in #150553. It allows to rewrite rule create properties.
Details
Rule create properties are returned by helper functions like
getNewRule(),getNewThresholdRule()and so on. So instead ofcreateRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })it allows to use a concise and a much more readable structurecreateRule(getNewRule({ index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' )).Possible improvements
The PR doesn't implement deep / nested fields merge. High level fields completely rewrite default values. Deep merge would allow to extend defaults with the provided rewrites. For example, overriding nested properties become tiresome quickly, as shown in the following code snippet:
If we implement deep merge, the readability could be greatly improved:
While it looks as a good idea we should take into consideration the fact that complete rewriting of default values can be a desired behavior. Engineers could tend to switch to
createRule({ ...getNewRule(), index: undefined, data_view_id: DATA_VIEW_ID, rule_id: '1' })to overcome deep merge. So it should be analysed carefully before implementing it.