[Cases] Case action refinements #175505
[Cases] Case action refinements #175505
Conversation
cnasikas
added
release_note:skip
| /** | ||
| * TODO: Verify limits | ||
| */ | ||
| tags: schema.arrayOf(schema.string({ minLength: 1, maxLength: 50 }), { |
There was a problem hiding this comment.
Rules do not impose any limits on tags (https://github.com/elastic/kibana/blob/80640cf1e5aeb967d53dc4cdaa03a71c4552a0d4/x-pack/plugins/alerting/common/routes/rule/apis/create/schemas/v1.ts). The cases limits are handled inside the case connector executor.
| .splice(0, MAX_TAGS_PER_CASE) | ||
| .map((tag) => tag.slice(0, MAX_LENGTH_PER_TAG)); |
There was a problem hiding this comment.
Impose the case limits on tags. Rules may have more tags than the allowed ones.
cnasikas
force-pushed
the
ca_left_overs
branch
from
a706b22 to
5e3820b
Compare
|
Pinging @elastic/response-ops (Team:ResponseOps) |
|
Pinging @elastic/response-ops-cases (Feature:Cases) |
| * The case connector will throw an error if the Kibana request | ||
| * is not define before executing the _run method | ||
| */ | ||
| const kibanaRequest = this.kibanaRequest as KibanaRequest; |
There was a problem hiding this comment.
I might not be understanding the full picture here, but since we removed private readonly kibanaRequest: KibanaRequest; at line 39,
shouldn't it be const kibanaRequest = this.connectorParams.kibanaRequest as KibanaRequest; here?
There was a problem hiding this comment.
If you check at the x-pack/plugins/actions/server/sub_action_framework/sub_action_connector.ts we set the kibanaRequest. It is already provided by the actions framework. The SubActionConnector class extends the SubActionConnector class. That's why we can access it like this. kibanaRequest .
## Summary Depends on: #166267, #170326, #169484, #173740, #173763, #178068, #178307, #178600, #180437 PRs: - #168370 - #169229 - #171754 - #172709 - #173012 - #175107 - #175452 - #175505 - #177033 - #178277 - #177139 - #179796 Fixes: #153837 ## Testing Run Kibana with `--run-examples` if you want to use the "Always firing" rule. Create a rule with a case action in observability and the stack. The security solution is not supported. You should not be able to assign a case action in a security solution rule. 1. Test the "Reopen closed cases" configuration. 2. Test the "Grouping by" configuration. Only one field is allowed. Not all fields are persisted in alerts. If you select a field not part of the alert the case action will create a case where the grouping value is set to `unknow`. 3. Test the "Time window" feature. You can comment out the validation to test for shorter times. 4. Verify that the case action is experimental. 5. Verify that based on the rule type the case is created in the correct solution. 6. Verify that you cannot create a rule with the case action on the basic license. 7. Verify that the execution of the case action fails if you do not have permission for cases. Pending work on the system actions framework level to not allow users to create rules with system actions where they do not have permission. 8. Stress test the case action by creating multiple rules. ### Checklist Delete any items that are not applicable to this PR. - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [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) ## Release notes Automatically create cases when an alert is triggered. --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: adcoelho <[email protected]> Co-authored-by: Janki Salvi <[email protected]>
Summary
This PR:
Checklist
Delete any items that are not applicable to this PR.
For maintainers