-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Cases] Add cases information to the alert's schema #147013
Conversation
cddb0b8
to
a0eca27
Compare
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
@elasticmachine merge upstream |
x-pack/plugins/rule_registry/common/assets/field_maps/technical_rule_field_map.test.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR adds the field to the schema, but where/when are we going to populate this field in the alert documents? Is this field written at some point after alert creation? |
Hey @marshallmain! When a user attaches an alert to a case, the cases plugin will update the alert's data to include the case ID it is attached to. The goal is to show in the alerts table, for each alert, the cases the alert is attached to. This work will be done in subsequent PRs. You can read more about it at #146864. |
@@ -51,6 +51,9 @@ const ALERT_SUPPRESSION_START = `${ALERT_SUPPRESSION_META}.start` as const; | |||
const ALERT_SUPPRESSION_END = `${ALERT_SUPPRESSION_META}.end` as const; | |||
const ALERT_SUPPRESSION_DOCS_COUNT = `${ALERT_SUPPRESSION_META}.docs_count` as const; | |||
|
|||
// Fields pertaining to the cases associated with the alert | |||
const ALERT_CASES_IDS = `${ALERT_NAMESPACE}.cases_ids` as const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to be annoying but we did agree on case_ids
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
bc4d628
to
6ad36ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @cnasikas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super, let's go!
… to a case (#147985) ## Summary PR #147013 extended the alert's schema to be able to store the case id an alert is attached to. This PR adds the ability to update the `case_ids` field of the alert when an alert is attached to a case. It also limits the number of cases an alert can be attached to ten. ### Permissions A user to attach an alert to a case needs a) to have read access to the solution via the kibana feature privileges and b) to have write access to the case. The user that did the request should not need to have written access to the alert for Cases to add the case ID to the alert's data. For that reason, the alert data client is extended to cover this particular need: update an alert even if the user has read access. ## Alerts client aside For future reference, the alerts client uses the request to check the kibana feature authorization but uses the internal system user to perform any write and get operations on the alert indices themselves. For security solution this means that a user with only read access to the security solution kibana feature, write access to cases, and no read or write access to the alert indices could attach an alert to a case and have the case id stored in the alert. For observability, users intentionally do not have access to the alert indices so we want to bypass the authorization check on the indices which is why the current alerts client uses an es client that is an internal system user. Related issue: #146864 ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Summary
This PR adds case information to the alerts' schema. More information here: #146864.
Checklist
Delete any items that are not applicable to this PR.
For maintainers