[Rules migration] Add pagination functionality to rules migration table (#11313) #202494

e40pud · 2024-12-02T14:53:47Z

Summary

Internal link to the feature details

With these changes we add pagination functionality for the rules migration table. This way we will improve the performance within the page.

Also, added as part of these PR:

moved install and install_translated routes to the rules/api folder; before those were located in rules/api/rules and made confusion
a new translation_stats route to return stats for the specific migration about the translated rules, like total number of the rules, and number of prebuilt, custom and installable rules
add Updated table column
small UI fixes:
- use correct icon for "SIEM rule migration"
- do not remove "Install translated rules" button and rather disable it when there are no installable rules
- do not allow user to update translation status via UI

…le (elastic#11313)

elasticmachine · 2024-12-02T14:53:50Z

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

elasticmachine · 2024-12-02T14:53:51Z

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

e40pud · 2024-12-02T14:55:03Z

...ugins/security_solution/public/siem_migrations/rules/components/rules_table/search_field.tsx

+import { EuiFieldSearch, EuiFlexItem } from '@elastic/eui';
+import * as i18n from './translations';
+
+const SearchBarWrapper = styled(EuiFlexItem)`


this style copied from similar rules management component x-pack/plugins/security_solution/public/detection_engine/rule_management_ui/components/rules_table/rules_table_filters/rule_search_field.tsx and we can adjust it if needed

e40pud · 2024-12-02T15:01:40Z

...lugins/security_solution/server/lib/siem_migrations/rules/data/rule_migrations_field_maps.ts

@@ -19,17 +19,17 @@ export const ruleMigrationsFieldMap: FieldMap<SchemaFieldMapKeys<Omit<RuleMigrat
  original_rule: { type: 'nested', required: true },
  'original_rule.vendor': { type: 'keyword', required: true },
  'original_rule.id': { type: 'keyword', required: true },
-  'original_rule.title': { type: 'keyword', required: true },
-  'original_rule.description': { type: 'keyword', required: false },
+  'original_rule.title': { type: 'text', required: true },


Updated schema to be able to search within title and description fields. For now we use only elastic_rule.title, but I was thinking that potentially we could extend search to other updated fields.

@semd let me know what you think about it

* use correct icon for "SIEM rule migration" * do not remove "Install translated rules" button and rather disable it when there are no installable rules * do not allow user to update translation status via UI

semd · 2024-12-03T15:43:21Z

.../security_solution/public/siem_migrations/rules/logic/use_get_migration_translation_stats.ts

+  const { addError } = useAppToasts();
+
+  return useGetMigrationTranslationStatsQuery(migrationId, {
+    onError: (error) => {
+      addError(error, { title: i18n.GET_MIGRATION_TRANSLATION_STATS_FAILURE });
+    },
+  });


I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?

No real reason, except of following rules management patterns :-) I think we do not need to overcomplicate things and can keep everything in one hook. I will fix that in a separate PR.

semd

LGTM

elasticmachine · 2024-12-03T17:22:24Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: 956db9b

Failed CI Steps

Jest Tests #10

Test Failures

[job] [logs] Jest Tests #10 / it should allow to add a new host
[job] [logs] Jest Tests #10 / useActionStatus should refresh statuses on refresh flag

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`securitySolution`	6307	6310	+3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`securitySolution`	14.6MB	14.6MB	+3.3KB

History

💛 Build #256215 was flaky 9acb183
💛 Build #256165 was flaky d17d49d

cc @e40pud

kibanamachine · 2024-12-03T17:50:29Z

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/12145332416

kibanamachine · 2024-12-03T17:55:25Z

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 202494

Questions ?

Please refer to the Backport tool documentation

e40pud · 2024-12-03T18:16:26Z

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

…le (elastic#11313) (elastic#202494) ## Summary [Internal link](elastic/security-team#10820) to the feature details With these changes we add pagination functionality for the rules migration table. This way we will improve the performance within the page. Also, added as part of these PR: * moved `install` and `install_translated` routes to the `rules/api` folder; before those were located in `rules/api/rules` and made confusion * a new `translation_stats` route to return stats for the specific migration about the translated rules, like `total` number of the rules, and number of `prebuilt`, `custom` and `installable` rules * add `Updated` table column * small UI fixes: * use correct icon for "SIEM rule migration" * do not remove "Install translated rules" button and rather disable it when there are no installable rules * do not allow user to update translation status via UI --------- Co-authored-by: kibanamachine <[email protected]> (cherry picked from commit a662233) # Conflicts: # x-pack/plugins/security_solution/common/api/quickstart_client.gen.ts # x-pack/plugins/security_solution/public/siem_migrations/rules/api/api.ts # x-pack/test/api_integration/services/security_solution_api.gen.ts

…on table (#11313) (#202494) (#202787) # Backport This will backport the following commits from `main` to `8.x`: - [[Rules migration] Add pagination functionality to rules migration table (#11313) (#202494)](#202494)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  --------- Co-authored-by: kibanamachine <[email protected]>

## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?

## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate? (cherry picked from commit 4d8f711)

…le (elastic#11313) (elastic#202494) ## Summary [Internal link](elastic/security-team#10820) to the feature details With these changes we add pagination functionality for the rules migration table. This way we will improve the performance within the page. Also, added as part of these PR: * moved `install` and `install_translated` routes to the `rules/api` folder; before those were located in `rules/api/rules` and made confusion * a new `translation_stats` route to return stats for the specific migration about the translated rules, like `total` number of the rules, and number of `prebuilt`, `custom` and `installable` rules * add `Updated` table column * small UI fixes: * use correct icon for "SIEM rule migration" * do not remove "Install translated rules" button and rather disable it when there are no installable rules * do not allow user to update translation status via UI --------- Co-authored-by: kibanamachine <[email protected]>

## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?

…le (elastic#11313) (elastic#202494) ## Summary [Internal link](elastic/security-team#10820) to the feature details With these changes we add pagination functionality for the rules migration table. This way we will improve the performance within the page. Also, added as part of these PR: * moved `install` and `install_translated` routes to the `rules/api` folder; before those were located in `rules/api/rules` and made confusion * a new `translation_stats` route to return stats for the specific migration about the translated rules, like `total` number of the rules, and number of `prebuilt`, `custom` and `installable` rules * add `Updated` table column * small UI fixes: * use correct icon for "SIEM rule migration" * do not remove "Install translated rules" button and rather disable it when there are no installable rules * do not allow user to update translation status via UI --------- Co-authored-by: kibanamachine <[email protected]>

## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?

…le (elastic#11313) (elastic#202494) ## Summary [Internal link](elastic/security-team#10820) to the feature details With these changes we add pagination functionality for the rules migration table. This way we will improve the performance within the page. Also, added as part of these PR: * moved `install` and `install_translated` routes to the `rules/api` folder; before those were located in `rules/api/rules` and made confusion * a new `translation_stats` route to return stats for the specific migration about the translated rules, like `total` number of the rules, and number of `prebuilt`, `custom` and `installable` rules * add `Updated` table column * small UI fixes: * use correct icon for "SIEM rule migration" * do not remove "Install translated rules" button and rather disable it when there are no installable rules * do not allow user to update translation status via UI --------- Co-authored-by: kibanamachine <[email protected]>

## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?

[Rules migration] Add pagination functionality to rules migration tab…

846bbe1

…le (elastic#11313)

e40pud requested a review from semd December 2, 2024 14:53

e40pud self-assigned this Dec 2, 2024

e40pud requested a review from a team as a code owner December 2, 2024 14:53

e40pud commented Dec 2, 2024

View reviewed changes

Remove obsolete code

f977ff4

e40pud commented Dec 2, 2024

View reviewed changes

[CI] Auto-commit changed files from 'yarn openapi:generate'

446ca6a

elastic-vault-github-plugin-prod bot requested a review from a team as a code owner December 2, 2024 15:28

e40pud added 4 commits December 2, 2024 17:10

Fix pagination

90c856a

Small UI fixes

d17d49d

* use correct icon for "SIEM rule migration" * do not remove "Install translated rules" button and rather disable it when there are no installable rules * do not allow user to update translation status via UI

Add Updated column

9acb183

Merge branch 'main' into security/siem-migrations/11313-pagination

956db9b

semd reviewed Dec 3, 2024

View reviewed changes

semd approved these changes Dec 3, 2024

View reviewed changes

e40pud merged commit a662233 into elastic:main Dec 3, 2024
8 checks passed

kibanamachine added the v9.0.0 label Dec 3, 2024

e40pud mentioned this pull request Dec 3, 2024

[8.x] [Rules migration] Add pagination functionality to rules migration table (#11313) (#202494) #202787

Merged

kibanamachine added the v8.18.0 label Dec 3, 2024

e40pud mentioned this pull request Dec 3, 2024

[Rules migration] Post merge feedback followups #202815

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Rules migration] Add pagination functionality to rules migration table (#11313) #202494

[Rules migration] Add pagination functionality to rules migration table (#11313) #202494

e40pud commented Dec 2, 2024 •

edited by kibanamachine

Loading

elasticmachine commented Dec 2, 2024

elasticmachine commented Dec 2, 2024

e40pud Dec 2, 2024

e40pud Dec 2, 2024

semd Dec 3, 2024

e40pud Dec 3, 2024

semd left a comment

elasticmachine commented Dec 3, 2024

kibanamachine commented Dec 3, 2024

kibanamachine commented Dec 3, 2024

e40pud commented Dec 3, 2024

[Rules migration] Add pagination functionality to rules migration table (#11313) #202494

[Rules migration] Add pagination functionality to rules migration table (#11313) #202494

Conversation

e40pud commented Dec 2, 2024 • edited by kibanamachine Loading

Summary

elasticmachine commented Dec 2, 2024

elasticmachine commented Dec 2, 2024

e40pud Dec 2, 2024

Choose a reason for hiding this comment

e40pud Dec 2, 2024

Choose a reason for hiding this comment

semd Dec 3, 2024

Choose a reason for hiding this comment

e40pud Dec 3, 2024

Choose a reason for hiding this comment

semd left a comment

Choose a reason for hiding this comment

elasticmachine commented Dec 3, 2024

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

Module Count

Async chunks

History

kibanamachine commented Dec 3, 2024

kibanamachine commented Dec 3, 2024

💔 All backports failed

Manual backport

Questions ?

e40pud commented Dec 3, 2024

💚 All backports created successfully

Questions ?

e40pud commented Dec 2, 2024 •

edited by kibanamachine

Loading