Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to specify custom id for alerts and actions #50210

Closed
mikecote opened this issue Nov 11, 2019 · 7 comments · Fixed by #89814
Closed

Ability to specify custom id for alerts and actions #50210

mikecote opened this issue Nov 11, 2019 · 7 comments · Fixed by #89814
Assignees
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

mikecote commented Nov 11, 2019

In certain cases like system generated alerts, you want to

  • prevent duplicates alerts from being created (idempotent alert creation)
  • be able to update specific rules over time
  • import and export rules without having duplicates appear

One suggested approach to doing this is to be able to assign custom IDs to alerts that would be the same in any installation, and prevent duplicates if running an alert setup multiple times.

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-services (Team:Stack Services)

@peterschretlen
Copy link
Contributor

@mikecote @FrankHassanabad it looks like this might be possible today, provided you use the alert client? It wouldn't be possible via the API, but looking at the client, you can pass SavedObjectsCreateOptions:

const createdAlert = await this.savedObjectsClient.create('alert', rawAlert, {
...options,
references,
});

And it looks like the options will allow you to override the ID:

export interface SavedObjectsCreateOptions extends SavedObjectsBaseOptions {
/** (not recommended) Specify an id for the document */
id?: string;
/** Overwrite existing documents (defaults to false) */
overwrite?: boolean;
/** {@inheritDoc SavedObjectsMigrationVersion} */
migrationVersion?: SavedObjectsMigrationVersion;
references?: SavedObjectReference[];
/** The Elasticsearch Refresh setting for this operation */
refresh?: MutatingOperationRefreshSetting;
}

@mikecote
Copy link
Contributor Author

In theory, yes as you can bypass the TypeScript type checks and it would pass along.

The one place that will stop you from doing so is here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/encrypted_saved_objects/server/saved_objects/encrypted_saved_objects_client_wrapper.ts#L58-L60.

On the good side, we're not too far from supporting custom ids as we would just need to revive this PR: #42762.

@bmcconaghy bmcconaghy added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) and removed Team:Stack Services labels Dec 12, 2019
@mikecote
Copy link
Contributor Author

mikecote commented Nov 23, 2020

A PR merged in the ESO plugin to enable us to do this enhancement.

@mikecote
Copy link
Contributor Author

I have a PR opened to support this (#89814) with the limitation that the id is UUID v1 or generated by SavedObjectsUtils.generateId().

@spong, this has been requested for the detection rules. Is the limitation of UUID v1 ok with you?

@mikecote mikecote self-assigned this Jan 30, 2021
@spong
Copy link
Member

spong commented Feb 1, 2021

I believe that should be fine @mikecote. We currently use UUID v4 for our rule_id's (which was our workaround for maintaining a static id), so we'd need to take that into consideration when migrating, but nothing immediately comes to mind that would be problematic with this limitation. I'll check with the team in our next sync just to be sure though.

@mikecote
Copy link
Contributor Author

mikecote commented Feb 1, 2021

@spong, actually, I think UUID v4 will work as well. It validates ok here: https://github.com/elastic/kibana/blob/master/src/core/server/saved_objects/service/lib/utils.ts#L78. But it's good to know UUIDs work for you 👍 I wanted to make sure your requirement didn't need to work with string / readable names.

@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants