WIP

x-pack/plugins/security_solution/docs/prebuilt_rules_customization_rfc.md

@@ -121,7 +121,7 @@ No changes will be needed either for the `security-rule` [mapping](https://githu
 
 Historically, migrations to Elasticsearch saved objects were carried out by a procedure in which the changes in the SO were described in a migration operation that would be carried out **during an upgrade to a specific Kibana version**. See `x-pack/plugins/alerting/server/saved_objects/migrations/index.ts` for a list of migrations of SO that take place when a user updates Kibana to a specific version.
 
-However, this mechanism is no longer supported by the Alerting Framework team - which maintained it - and we therefore have to find an alternative strategy: we will perform the migration of the saved objects directly in the Detection API's endpoints that interact with them. This means that, instead of all of a user's saved object being migrated in a single operation during a Kibana update, the SO will be migrated when the pertinent endpoints are called. In the next section, we describe which those endpoints are.
+However, this mechanism is no longer supported by the Alerting Framework team - which maintained it - and we therefore have to find an alternative strategy. Therefore, we will perform the migration of the saved objects directly in the Detection API's endpoints that interact with them. This means that, instead of all of a user's saved object being migrated in a single operation during a Kibana update, the SO will be migrated when the pertinent endpoints are called. In the next section, we describe which those endpoints are.
 
 Since the migration of rules will be performed as the user calls the pertinent endpoints, the migration of the saved objects will be carried out progressively and incrementally: the SO will be migrated only when a endpoint that handles it is called by the user. We therefore have to assume that, at any given point in time, a user may have a mix of migrated and non-migrated rule saved objects. Consequently, we must continue supporting both versions of SOs.
 
@@ -158,7 +158,7 @@ All of the following endpoints either fetch the rule before updating it, or send
  - This endpoint also includes a `dry_run` mode that is executed to evaluate preconditions and warn the user before executing the actual request. No migration logic should take place for dry run requests, i.e when `dry_run=true`, since we never write to ES when this parameter is set to `true`.
  - Actions that should perform migration logic:
  - Edit:
- - endpoint should migrate rule while performing migration. We can take advantage of the `ruleParamsModifier` to carry out the migration, regardless of the type of edit that is being performed.
+ - endpoint should migrate rule while aookying bulk editing actions. We can take advantage of the `ruleParamsModifier` to carry out the migration, regardless of the type of edit that is being performed.
  - Actions that should **not** perform migration logic:
  - Enable
  - Disable