-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Implemented actions server API for supporting preconfigured connectors #62382
Implemented actions server API for supporting preconfigured connectors #62382
Conversation
…s defined in kibana.yaml
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
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.
This is great, heading towards the right direction!
I think we should keep using the actions
terminology in the server side (variable names, TS interfaces, etc) instead of introducing connectors (front-end term).
It looks like some tests need to be fixed / updated (changing expected result in switch statements). Let me know if you need help with those.
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 from stack monitoring!
…gured-connectors-api # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
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, but I'd like to see that comment corrected or, ideally, covered by a unit test so that it can't go out of date again.
…gured-connectors-api # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
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 - made a few small comments/questions
I think there may be a couple more validation things we should do, in a follow-on issue/PR:
- what happens if two pre-configured actions have the same id?
- what happens if someone creates a pre-configured action, that has the same id as an non-pre-configured action. Thinking someone trying to hack the system. User A creates a new slack action. User B gets the id for that action, creates a pre-configured action with the same id. Which one will be used?
@@ -29,35 +36,12 @@ interface CreateOptions { | |||
action: Action; | |||
} | |||
|
|||
interface FindOptions { |
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.
I guess we we never need this? :-)
Seems like if we do need something like this in the future, if listing everything is too much (even with client filtering), we could provide some simple search capabilities that would work in both ES and "manual" searches through the pre-configured ones. But I guess pagination is something we just can't support anymore ...
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.
We discussed this with @mikecote and didn't find any real usage of 'find' API method in the Kibana plugins our UI implementation - seems like we don't need this (at least for now)
@@ -83,6 +84,7 @@ describe('create()', () => { | |||
}); | |||
expect(result).toEqual({ | |||
id: '1', | |||
isPreconfigured: false, |
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.
I'm wondering why isPreconfigured
is something we're returning here. Guessing it will be nice, eventually, to somehow indicate this to the user, with some kind of "lock" icon or something. But I don't think it's really needed for anything but that, is it? Just curious, I'm +1 on having it, now that I see it, but guessing I might not have returned it if I had implemented this PR.
const actionsConfig = (await this.config) as ActionsConfig; | ||
const actionsConfigUtils = getActionsConfigurationUtilities(actionsConfig); | ||
|
||
this.preconfiguredActions.push( |
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.
I think we should probably be running these through the actionType validators, to make sure the config/secrets get validated by the actionType. I don't think that's happening right now. I made some comments in my earlier review about other validations we should be doing, I think it's fine to do them all in a separate issue/PR.
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
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.
Changes LGTM! 👍
…gured-connectors-api # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
💛 Build succeeded, but was flaky
Test FailuresKibana Pipeline / kibana-xpack-agent / Sorts by activated rules.Signal detection rules Sorts by activated rulesStandard Out
Stack Trace
History
To update your PR or re-run it, just comment with: |
elastic#62382) * Implemented actions server API for supporting preconfigured connectors defined in kibana.yaml * Fixed type check * Fixed due to comments and extended functional tests * Fixed tests and renamed connectors * fixed jest tests * Fixed type checks * Fixed failing alert save * Fixed alert client tests * fixed type checks * Fixed language check error * Fixed jest tests * Added missing comments and docs * fixed due to comments * Fixed json config for preconfigured * fixed type check, reverted config * config experiment with json stringify * revert experiment * Removed the spaces from connector names in config
#62382) (#62980) * Implemented actions server API for supporting preconfigured connectors defined in kibana.yaml * Fixed type check * Fixed due to comments and extended functional tests * Fixed tests and renamed connectors * fixed jest tests * Fixed type checks * Fixed failing alert save * Fixed alert client tests * fixed type checks * Fixed language check error * Fixed jest tests * Added missing comments and docs * fixed due to comments * Fixed json config for preconfigured * fixed type check, reverted config * config experiment with json stringify * revert experiment * Removed the spaces from connector names in config
Summary
Current PR exposing server API for preconfigured connectors defined in kibana.yaml.
api/actions/get/{id}
to support return preconfigured connector by idapi/actions/_getAll
for getting all connectors - preconfigured and saved objects. This endpoint is supposed to be used instead ofapi/actions/_find
on the UI side for building Connectors table (currently all paging, sorting and filtering is done on the UI side).Checklist
Delete any items that are not applicable to this PR.