[Security Solution] Add `history_window_start` and `new_terms_fields` editable fields #200304

nikitaindik · 2024-11-15T14:52:56Z

Partially addresses: #171520

Summary

Changes in this PR:

history_window_start and new_terms_fields are now editable in the Rule Upgrade flyout
Extracted fields into separate components that are easier to reuse (NewTermsFieldsEdit and HistoryWindowStartEdit)

Testing

Ensure the prebuiltRulesCustomizationEnabled feature flag is enabled.
To simulate the availability of prebuilt rule upgrades, downgrade a currently installed prebuilt rule using the PATCH api/detection_engine/rules API.
- Set version: 1 in the request body to downgrade it to version 1.
- Modify other rule fields in the request body as needed to test the changes.

elasticmachine · 2024-11-15T14:55:01Z

Pinging @elastic/security-detections-response (Team:Detections and Resp)

elasticmachine · 2024-11-15T14:55:02Z

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

elasticmachine · 2024-11-15T14:55:03Z

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

maximpn

Hi @nikitaindik,

I looked through the code and left comments according to my findings.

Testing revealed a problem that validation doesn't run in Prebuilt Rules Customization workflow

it's possible to save empty fields

Screen.Recording.2024-11-18.at.10.00.33.mov

it's possible to save zero history window size

Screen.Recording.2024-11-18.at.10.02.37.mov

while the validation works in the rule editing form

maximpn · 2024-11-18T08:15:26Z

x-pack/plugins/security_solution/public/common/utils/history_window.ts

+  if (historyStart.startsWith('now-')) {
+    return historyStart.substring(4);
+  } else {
+    return historyStart;
+  }


Suggested change

if (historyStart.startsWith('now-')) {

return historyStart.substring(4);

} else {

return historyStart;

}

if (historyStart.startsWith('now-')) {

return historyStart.substring(4);

}

return historyStart;

maximpn · 2024-11-18T08:16:04Z

...tion_engine/rule_creation/components/history_window_start_edit/history_window_start_edit.tsx

+import { ScheduleItemField } from '../schedule_item_field';
+import { UseField } from '../../../../shared_imports';
+
+const componentProps = {


nit: Constants should have capital case COMPONENT_PROPS.

maximpn · 2024-11-18T08:28:52Z

...ic/detection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_edit.tsx

+export function NewTermsFieldsEdit({ path, browserFields }: NewTermsFieldsEditProps): JSX.Element {
+  const componentProps = useMemo(() => ({ browserFields }), [browserFields]);
+
+  return (
+    <UseField path={path} component={NewTermsFieldsEditField} componentProps={componentProps} />
+  );
+}


You could memoize the whole component to make the code a bit shorter

Suggested change

export function NewTermsFieldsEdit({ path, browserFields }: NewTermsFieldsEditProps): JSX.Element {

const componentProps = useMemo(() => ({ browserFields }), [browserFields]);

return (

<UseField path={path} component={NewTermsFieldsEditField} componentProps={componentProps} />

);

}

export const NewTermsFieldsEdit = memo(function NewTermsFieldsEdit({ path, browserFields }: NewTermsFieldsEditProps): JSX.Element {

return (

<UseField path={path} component={NewTermsFieldsEditField} componentProps={{browserFields}} />

);

});

Wrapping a named function instead of an arrow function provides a display name to React.

maximpn · 2024-11-18T08:31:16Z

...ic/detection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_edit.tsx

+
+interface NewTermsFieldsEditProps {
+  path: string;
+  browserFields: DataViewFieldBase[];


Do you know what browser in that context mean?

It looks simpler to stick to simple fieldNames: string[].

maximpn · 2024-11-18T08:32:25Z

...ection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_edit_field.tsx

@@ -39,4 +39,4 @@ export const NewTermsFieldsComponent: React.FC<NewTermsFieldsProps> = ({
  return <Field field={field} idAria={fieldDescribedByIds} euiFieldProps={fieldEuiFieldProps} />;
 };

-export const NewTermsFields = React.memo(NewTermsFieldsComponent);
+export const NewTermsFieldsEditField = React.memo(NewTermsFieldsEditFieldComponent);


nit: It looks like too much memoization here. When the top component NewTermsFieldsEdit is memoized it doesn't look like useMemo and memo are required here since the component will be anyway re-rendered when fields change.

maximpn · 2024-11-18T08:36:14Z

..._details/three_way_diff/final_edit/fields/new_terms_fields/new_terms_fields_edit_adapter.tsx

+  finalDiffableRule,
+}: NewTermsFieldsEditAdapterProps): JSX.Element {
+  const { dataView } = useDiffableRuleDataView(finalDiffableRule);
+  const termsAggregationFields = useTermsAggregationFields(dataView?.fields || []);


Suggested change

const termsAggregationFields = useTermsAggregationFields(dataView?.fields || []);

const termsAggregationFields = useTermsAggregationFields(dataView?.fields ?? []);

maximpn · 2024-11-18T08:37:25Z

...ule_details/three_way_diff/final_edit/fields/new_terms_fields/new_terms_fields_edit_form.tsx

+function deserializer(defaultValue: FormData): NewTermsFieldsFormData {
+  return {
+    newTermsFields: defaultValue.new_terms_fields,
+  };
+}
+
+function serializer(formData: FormData): { new_terms_fields: NewTermsFields } {
+  return {
+    new_terms_fields: formData.newTermsFields,
+  };
+}


Could you use new_terms_fields path in NewTermsFieldsEditAdapter and omit deserializer/serializer?

maximpn · 2024-11-18T08:41:52Z

x-pack/plugins/security_solution/public/common/utils/history_window.ts

+ * @param historyStart - History start string to convert. For example, "now-30d".
+ * @returns Converted size string. For example, "30d".
+ */
+export const convertHistoryStartToSize = (historyStart: string) => {


now-30d is called Date Math. The output is rather duration than size.

Let's rename this pair of functions to convertDateMathToDuration and convertDurationToDateMath.

maximpn · 2024-11-18T09:06:31Z

...ection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_edit_field.tsx


-export const NewTermsFieldsComponent: React.FC<NewTermsFieldsProps> = ({
+export const NewTermsFieldsEditFieldComponent: React.FC<NewTermsFieldsProps> = ({


It's better to name it NewTermsFieldsField for coherence.

maximpn · 2024-11-18T09:12:03Z

...ils/three_way_diff/final_edit/fields/history_window_start/history_window_start_edit_form.tsx

+}
+
+export const historyWindowFormSchema = {
+  historyWindowSize: schema.historyWindowSize,


From architectural POV it looks better to bring historyWindowSize and newTermsFields configurations like label, helpText and etc to the corresponding edit components. When edit components rendered conditionally only for new terms rule types validation doesn't required check for the rule type.

The only thing which needs to be addressed is user input persistence. But it can be easily done via a hook.

That's a great idea! I was also considering a way to share schemas but couldn't figure out how. Your approach actually works. I've refactored the code accordingly.

nikitaindik · 2024-11-18T20:32:19Z

Thanks for the review and testing, @maximpn! I've addressed your feedback. Please take a look.

nkhristinin

tested locally - LGTM

maximpn

@nikitaindik thanks for addressing my comments 🙏

I found new issues and left comments about them.

maximpn · 2024-11-19T10:07:24Z

...ic/detection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_edit.tsx

+    {
+      validator: (
+        ...args: Parameters<ValidationFunc>
+      ): ReturnType<ValidationFunc<{}, ERROR_CODE>> | undefined => {


nit: Return type could be omitted.

maximpn · 2024-11-19T10:54:37Z

...c/detection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_field.tsx


-export const NewTermsFieldsComponent: React.FC<NewTermsFieldsProps> = ({
-  browserFields,
+const NewTermsFieldsEditFieldComponent: React.FC<NewTermsFieldsProps> = ({


Component suffix looks excessive here. Could we name it NewTermsFieldsField or NewTermsFieldsFormField?

The function could be defined simpler

const NewTermsFieldsField = memo(function NewTermsFieldsField(): JSX.Element { // ... });

maximpn · 2024-11-19T10:58:54Z

...ity_solution/public/detection_engine/rule_creation_ui/components/step_define_rule/schema.tsx

@@ -555,106 +553,8 @@ export const schema: FormSchema<DefineStepRule> = {
      },
    ],
  },
-  newTermsFields: {


After removing labels from the schema labels should be added to x-pack/plugins/security_solution/public/detection_engine/rule_creation_ui/components/description_step/index.tsx in getDescriptionItem() as if (filed === 'newTermsFields') and if (field === 'historyWindowSize ') entries where labels could be imported from components. Without that readonly view looks like

And on main

maximpn · 2024-11-19T11:00:26Z

...ublic/detection_engine/rule_creation_ui/validators/history_window_start_validator_factory.ts

+  const field = form.getFields()[path] as FieldHook<string> | undefined;
+  const value = field?.value ?? '';


value should be extracted from args

const [{ value, path, form }] = args;

maximpn · 2024-11-19T11:05:51Z

...ublic/detection_engine/rule_creation_ui/validators/history_window_start_validator_factory.ts

+  const numberMatchResult = value.match(/\d+/g);
+
+  if (numberMatchResult === null) {
+    return {
+      code: 'ERR_NOT_INT_NUMBER',
+      path,
+      message: i18n.translate(
+        'xpack.securitySolution.detectionEngine.validations.stepDefineRule.historyWindowSize.errNumber',
+        {
+          defaultMessage: 'History window size must be a positive number.',
+        }
+      ),
+    };
+  }
+
+  const numericValue = parseInt(numberMatchResult[0], 10);
+
+  if (numericValue <= 0) {
+    return {
+      code: 'ERR_MIN_LENGTH',
+      path,
+      message: i18n.translate(
+        'xpack.securitySolution.detectionEngine.validations.stepDefineRule.historyWindowSize.errMin',
+        {
+          defaultMessage: 'History window size must be greater than 0.',
+        }
+      ),
+    };
+  }


The validation logic could be simplified by using parseInt() only and checking for NaN

Suggested change

const numberMatchResult = value.match(/\d+/g);

if (numberMatchResult === null) {

return {

code: 'ERR_NOT_INT_NUMBER',

path,

message: i18n.translate(

'xpack.securitySolution.detectionEngine.validations.stepDefineRule.historyWindowSize.errNumber',

{

defaultMessage: 'History window size must be a positive number.',

}

),

};

}

const numericValue = parseInt(numberMatchResult[0], 10);

if (numericValue <= 0) {

return {

code: 'ERR_MIN_LENGTH',

path,

message: i18n.translate(

'xpack.securitySolution.detectionEngine.validations.stepDefineRule.historyWindowSize.errMin',

{

defaultMessage: 'History window size must be greater than 0.',

}

),

};

}

const historyWindowSize = parseInt(value, 10);

if (Number.isNaN(historyWindowSize)) {

return {

code: 'ERR_NOT_INT_NUMBER',

path,

message: i18n.translate(

'xpack.securitySolution.detectionEngine.validations.stepDefineRule.historyWindowSize.errNumber',

{

defaultMessage: 'History window size must be a positive number.',

}

),

};

}

if (historyWindowSize <= 0) {

return {

code: 'ERR_MIN_LENGTH',

path,

message: i18n.translate(

'xpack.securitySolution.detectionEngine.validations.stepDefineRule.historyWindowSize.errMin',

{

defaultMessage: 'History window size must be greater than 0.',

}

),

};

}

maximpn · 2024-11-19T11:09:39Z

...ublic/detection_engine/rule_creation_ui/validators/history_window_start_validator_factory.ts

+export function historyWindowStartValidationFactory(
+  ...args: Parameters<ValidationFunc>
+): ReturnType<ValidationFunc<{}, ERROR_CODE>> | undefined {


The function should be a factory. It means it constructs a functions and returns it. The implementation is a validator function. Correct implementation should look like

export function historyWindowStartValidationFactory(): ValidationFunc<FormData, ERROR_CODE, unknown> { return (...args) => { // Your implementation goes here }; }

maximpn · 2024-11-19T11:21:44Z

...on/public/detection_engine/rule_creation_ui/validators/new_terms_fields_validator_factory.ts

+export function newTermsFieldsValidatorFactory(
+  ...args: Parameters<ValidationFunc>
+): ReturnType<ValidationFunc<{}, ERROR_CODE>> | undefined {
+  return (
+    fieldValidators.emptyField(
+      i18n.translate(
+        'xpack.securitySolution.detectionEngine.createRule.stepDefineRule.newTermsFieldsMin',
+        {
+          defaultMessage: 'A minimum of one field is required.',
+        }
+      )
+    )(...args) ??
+    fieldValidators.maxLengthField({
+      length: MAX_NUMBER_OF_NEW_TERMS_FIELDS,
+      message: i18n.translate(
+        'xpack.securitySolution.detectionEngine.validations.stepDefineRule.newTermsFieldsMax',
+        {
+          defaultMessage: 'Number of fields must be 3 or less.',
+        }
+      ),
+    })(...args)
+  );
+}


We shouldn't compose validators like that. The best place to compose validators is NewTermsFieldsEdit component. new_terms_fields_edit.tsx should have the following

const NEW_TERMS_FIELDS_CONFIG = { ... validations: [ { validator: fieldValidators.emptyField( i18n.translate( 'xpack.securitySolution.detectionEngine.createRule.stepDefineRule.newTermsFieldsMin', { defaultMessage: 'A minimum of one field is required.', } ) ), }, { validator: fieldValidators.maxLengthField({ length: MAX_NUMBER_OF_NEW_TERMS_FIELDS, message: i18n.translate( 'xpack.securitySolution.detectionEngine.validations.stepDefineRule.newTermsFieldsMax', { defaultMessage: 'Number of fields must be 3 or less.', } ), }), }, ], };

i18n messages should be extracted to translations.ts.

As a side comment. fieldValidators.maxLengthField is a validator factory. It's a high order function returning a validator function.

maximpn · 2024-11-19T11:24:30Z

...ents/rule_details/three_way_diff/final_readonly/fields/new_terms_fields/new_terms_fields.tsx

@@ -16,6 +16,10 @@ interface NewTermsFieldsReadOnlyProps {
 }

 export function NewTermsFieldsReadOnly({ newTermsFields }: NewTermsFieldsReadOnlyProps) {
+  if (!newTermsFields.length) {


It looks like newTermsFields.length should always be more than zero according to form validation. Why do we need this condition? Event if newTermsFields has zero length it should render properly.

maximpn · 2024-11-19T12:03:54Z

...tion_engine/rule_creation/components/history_window_start_edit/history_window_start_edit.tsx

+}
+
+const HISTORY_WINDOW_START_FIELD_CONFIG: FieldConfig<HistoryWindowStart> = {
+  label: i18n.translate(


nit: Translations could be moved to translations.ts.

maximpn · 2024-11-19T12:04:30Z

...tion_engine/rule_creation/components/history_window_start_edit/history_window_start_edit.tsx

+  validations: [
+    {
+      validator: (
+        ...args: Parameters<ValidationFunc>
+      ): ReturnType<ValidationFunc<{}, ERROR_CODE>> | undefined =>
+        historyWindowStartValidationFactory(...args),
+    },
+  ],


Suggested change

validations: [

{

validator: (

...args: Parameters<ValidationFunc>

): ReturnType<ValidationFunc<{}, ERROR_CODE>> | undefined =>

historyWindowStartValidationFactory(...args),

},

],

validations: [

{

validator: historyWindowStartValidationFactory(),

},

],

nikitaindik · 2024-11-19T17:05:04Z

Thanks for reviewing again, @maximpn! I've addressed the comments. Please take another look.

maximpn

@nikitaindik I had a look a left a few comments. The PR works well but let's do the final polishing.

maximpn · 2024-11-20T08:07:05Z

...tion_engine/rule_creation/components/history_window_start_edit/history_window_start_edit.tsx

-        ...args: Parameters<ValidationFunc>
-      ): ReturnType<ValidationFunc<{}, ERROR_CODE>> | undefined =>
-        historyWindowStartValidationFactory(...args),
+      validator: (...args: Parameters<ValidationFunc>) => {


nit: Parameters<ValidationFunc> could be omitted.

maximpn · 2024-11-20T08:07:46Z

...tion_engine/rule_creation/components/history_window_start_edit/history_window_start_edit.tsx

+        const [{ path, value }] = args;
+
+        const historyWindowSize = Number.parseInt(String(value), 10);
+
+        if (Number.isNaN(historyWindowSize)) {
+          return {
+            code: 'ERR_NOT_INT_NUMBER',
+            path,
+            message: i18n.MUST_BE_POSITIVE_INTEGER_VALIDATION_ERROR,
+          };
+        }
+
+        if (historyWindowSize <= 0) {
+          return {
+            code: 'ERR_MIN_LENGTH',
+            path,
+            message: i18n.MUST_BE_GREATER_THAN_ZERO_VALIDATION_ERROR,
+          };
+        }
+      },


I'd recommend to move the validation to a separate function in a separate file for better readability.

maximpn · 2024-11-20T08:07:59Z

...ic/detection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_edit.tsx

-import { i18n } from '@kbn/i18n';
-import type { ERROR_CODE, ValidationFunc } from '../../../../shared_imports';
-import { FIELD_TYPES, UseField } from '../../../../shared_imports';
+// import { i18n } from '@kbn/i18n';


Should it be removed?

maximpn · 2024-11-20T08:12:59Z

...c/detection_engine/rule_creation/components/new_terms_fields_edit/new_terms_fields_field.tsx

+    style: { width: `${FIELD_COMBO_BOX_WIDTH}px` },
+  };
+
+  return <Field field={field} idAria={fieldDescribedByIds} euiFieldProps={fieldEuiFieldProps} />;


It could use ComboBoxField directly. It doesn't look like changing a field type makes sense here.

nikitaindik · 2024-11-20T14:12:52Z

@maximpn New feedback addressed. Please take a new look.

maximpn

@nikitaindik Thanks for improvements it LGTM 👍

nikitaindik · 2024-12-05T08:41:04Z

Thanks, everyone, for your reviews and testing! @xcrzx still needs to review it. I've transitioned this to draft since the team is now focusing on high-priority Rule Customization tickets, and we want to avoid daily notifications from less important PRs like this one. I will reopen it for review once we finish the other work and notify @xcrzx to re-review.

… is merged

xcrzx

I manually tested the changes in this PR locally and verified the affected fields: history window, new terms, and schedule. I tested various scenarios involving modifications to these fields using both the rule editing form and the rule upgrade form. I also confirmed that the fields display correctly on the rule details page and tested rule upgrade flows with the feature flag disabled. I didn’t encounter any issues.

I’m skipping a review of the code changes since @maximpn has already reviewed them.

elasticmachine · 2024-12-18T17:08:31Z

💛 Build succeeded, but was flaky

Failed CI Steps

FTR Configs #76

Test Failures

[job] [logs] FTR Configs #76 / Visualizations - Group 3 lens app - TSVB Open in Lens Table should convert aggregate by to split row dimension

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`securitySolution`	6435	6449	+14

Async chunks

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

id	before	after	diff
`securitySolution`	21.4MB	21.4MB	+2.8KB

History

💛 Build #261333 was flaky 71c52f0
💔 Build #260805 failed 4221186
💔 Build #260671 failed 7a3f474
💔 Build #255593 failed 09e68ef
💛 Build #254322 was flaky 399285c
💛 Build #252765 was flaky 762530b

cc @nikitaindik

kibanamachine · 2024-12-18T17:09:47Z

Starting backport for target branches: 8.x

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

kibanamachine · 2024-12-18T17:14:56Z

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts You might need to backport the following PRs to 8.x: - [index management] Better privilege checking for component index templates (#202251)

Manual backport

To create the backport manually run:

node scripts/backport --pr 200304

Questions ?

Please refer to the Backport tool documentation

nikitaindik · 2024-12-18T19:51:45Z

💚 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

… editable fields (elastic#200304) **Partially addresses: elastic#171520 ## Summary **Changes in this PR**: - `history_window_start` and `new_terms_fields` are now editable in the Rule Upgrade flyout - Extracted fields into separate components that are easier to reuse (`NewTermsFieldsEdit` and `HistoryWindowStartEdit`) <img width="1392" alt="Schermafbeelding 2024-11-15 om 15 51 04" src="https://github.com/user-attachments/assets/d00b7b3d-7c01-4041-b940-390660a069a9"> ### Testing - Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled. - To simulate the availability of prebuilt rule upgrades, downgrade a currently installed prebuilt rule using the `PATCH api/detection_engine/rules` API. - Set `version: 1` in the request body to downgrade it to version 1. - Modify other rule fields in the request body as needed to test the changes.

…ields` editable fields (#200304) (#204830) # Backport This will backport the following commits from `main` to `8.x`: - [[Security Solution] Add `history_window_start` and `new_terms_fields` editable fields (#200304)](#200304)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)

… editable fields (elastic#200304) **Partially addresses: elastic#171520 ## Summary **Changes in this PR**: - `history_window_start` and `new_terms_fields` are now editable in the Rule Upgrade flyout - Extracted fields into separate components that are easier to reuse (`NewTermsFieldsEdit` and `HistoryWindowStartEdit`) <img width="1392" alt="Schermafbeelding 2024-11-15 om 15 51 04" src="https://github.com/user-attachments/assets/d00b7b3d-7c01-4041-b940-390660a069a9"> ### Testing - Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled. - To simulate the availability of prebuilt rule upgrades, downgrade a currently installed prebuilt rule using the `PATCH api/detection_engine/rules` API. - Set `version: 1` in the request body to downgrade it to version 1. - Modify other rule fields in the request body as needed to test the changes.

nikitaindik self-assigned this Nov 15, 2024

nikitaindik marked this pull request as ready for review November 15, 2024 14:54

nikitaindik requested review from a team as code owners November 15, 2024 14:54

nikitaindik requested review from nkhristinin and dplumlee November 15, 2024 14:54

nikitaindik requested review from maximpn and removed request for dplumlee November 15, 2024 14:55

banderror added v9.0.0 backport:version Backport to applied version labels v8.17.0 and removed backport:prev-minor Backport to (8.x) the previous minor version (i.e. one version back from main) labels Nov 15, 2024

maximpn reviewed Nov 18, 2024

View reviewed changes

maximpn mentioned this pull request Nov 18, 2024

[Security Solution] Rework Update flyout to display all field updates and build Three-Way-Diff field component #171520

Open

69 tasks

nikitaindik requested review from maximpn and xcrzx November 18, 2024 20:32

nkhristinin approved these changes Nov 19, 2024

View reviewed changes

maximpn reviewed Nov 19, 2024

View reviewed changes

nikitaindik requested a review from maximpn November 19, 2024 17:04

maximpn reviewed Nov 20, 2024

View reviewed changes

nikitaindik requested a review from maximpn November 20, 2024 14:12

maximpn added v8.18.0 and removed v8.17.0 labels Nov 21, 2024

maximpn approved these changes Nov 21, 2024

View reviewed changes

banderror marked this pull request as draft December 4, 2024 16:14

nikitaindik marked this pull request as ready for review December 16, 2024 09:10

Move files into a new dir structure after the Sustainable Kibana Arch…

71c52f0

… is merged

nikitaindik force-pushed the new-terms-editable-fields branch from 4221186 to 71c52f0 Compare December 17, 2024 11:46

xcrzx approved these changes Dec 18, 2024

View reviewed changes

Merge branch 'main' into new-terms-editable-fields

1ae5db3

nikitaindik enabled auto-merge (squash) December 18, 2024 15:20

nikitaindik merged commit 639143a into elastic:main Dec 18, 2024
9 checks passed

nikitaindik mentioned this pull request Dec 18, 2024

[8.x] [Security Solution] Add history_window_start and new_terms_fields editable fields (#200304) #204830

Merged

kibanamachine mentioned this pull request Dec 18, 2024

[Security Solution] Add threshold, machine_learning_job_id and anomaly_threshold editable fields #200323

Merged

	const termsAggregationFields = useTermsAggregationFields(dataView?.fields \|\| []);
	const termsAggregationFields = useTermsAggregationFields(dataView?.fields ?? []);


		export const NewTermsFieldsComponent: React.FC<NewTermsFieldsProps> = ({
		export const NewTermsFieldsEditFieldComponent: React.FC<NewTermsFieldsProps> = ({

		const field = form.getFields()[path] as FieldHook<string> \| undefined;
		const value = field?.value ?? '';

[Security Solution] Add history_window_start and new_terms_fields editable fields #200304

[Security Solution] Add history_window_start and new_terms_fields editable fields #200304

Conversation

nikitaindik commented Nov 15, 2024 • edited by kibanamachine Loading

Summary

Testing

elasticmachine commented Nov 15, 2024

elasticmachine commented Nov 15, 2024

elasticmachine commented Nov 15, 2024

maximpn left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikitaindik commented Nov 18, 2024

nkhristinin left a comment

Choose a reason for hiding this comment

maximpn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikitaindik commented Nov 19, 2024

maximpn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikitaindik commented Nov 20, 2024

maximpn left a comment

Choose a reason for hiding this comment

nikitaindik commented Dec 5, 2024

xcrzx left a comment

Choose a reason for hiding this comment

elasticmachine commented Dec 18, 2024

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

Module Count

Async chunks

History

kibanamachine commented Dec 18, 2024

kibanamachine commented Dec 18, 2024

💔 All backports failed

Manual backport

Questions ?

nikitaindik commented Dec 18, 2024

💚 All backports created successfully

Questions ?

[Security Solution] Add `history_window_start` and `new_terms_fields` editable fields #200304

[Security Solution] Add `history_window_start` and `new_terms_fields` editable fields #200304

nikitaindik commented Nov 15, 2024 •

edited by kibanamachine

Loading

maximpn left a comment •

edited

Loading