Retain APIKey when disabling/enabling a rule#131581
Retain APIKey when disabling/enabling a rule#131581ersin-erdal merged 24 commits intoelastic:mainfrom
Conversation
…retain-api-key � Conflicts: � x-pack/plugins/triggers_actions_ui/public/application/sections/rules_list/components/rules_list.test.tsx � x-pack/plugins/triggers_actions_ui/public/application/sections/rules_list/components/rules_list.tsx
…34-retain-api-key
|
Ran through the PR together and had the following updates:
Here's a quick mockup of the page header buttons on the detail page. I kept refresh exposed alongside View in app. We are updating the page to place the disable button within the page more clearly, but whatever the result of that, I think we'll want to duplicate that action here. Showing a user with the option to update the api key and one without. |
…retain-api-key
|
Pinging @elastic/response-ops (Team:ResponseOps) |
|
Just starting a review - thinking we should probably have some functional tests, but not quite clear to me what they should do! I don't believe we expose the API key in any HTTP outputs, do we? On purpose. Or via public types. Only immediate thought is to get the rule SO directly in the function test, unencrypted, and see if there is a key set. |
pmuellr
left a comment
There was a problem hiding this comment.
I review the server side code - surprised it's so small! Wondering what we're missing :-)
I'll review the UX code next, but thought I'd send along the current comments, which are mostly questions.
x-pack/plugins/alerting/server/rules_client/tests/enable.test.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Looking good! Did a pass of the code. I think it would be good to get a 👍 from R&AM team as well (cc @XavierM). Left some feedback and will approve after my questions are answered.
thinking we should probably have some functional tests, but not quite clear to me what they should do!
I do think we should add some functional tests. Something to ensure an API key isn't overwritten on enable when it exists. Ensure disable then enable preserves the API key, maybe?
...gins/triggers_actions_ui/public/application/components/update_api_key_modal_confirmation.tsx
Outdated
Show resolved
Hide resolved
...gins/triggers_actions_ui/public/application/components/update_api_key_modal_confirmation.tsx
Outdated
Show resolved
Hide resolved
...gins/triggers_actions_ui/public/application/components/update_api_key_modal_confirmation.tsx
Outdated
Show resolved
Hide resolved
...gins/triggers_actions_ui/public/application/components/update_api_key_modal_confirmation.tsx
Show resolved
Hide resolved
Support updating multiple rules (Future proof)
mdefazio
left a comment
There was a problem hiding this comment.
Tiny nit to lowercase API key.
...gins/triggers_actions_ui/public/application/components/update_api_key_modal_confirmation.tsx
Outdated
Show resolved
Hide resolved
...gers_actions_ui/public/application/sections/rule_details/components/rule_actions_popover.tsx
Outdated
Show resolved
Hide resolved
...actions_ui/public/application/sections/rules_list/components/collapsed_item_actions.test.tsx
Outdated
Show resolved
Hide resolved
...gers_actions_ui/public/application/sections/rules_list/components/collapsed_item_actions.tsx
Outdated
Show resolved
Hide resolved
...gins/triggers_actions_ui/public/application/components/update_api_key_modal_confirmation.tsx
Outdated
Show resolved
Hide resolved
...rs_actions_ui/public/application/sections/rule_details/components/rule_actions_popopver.scss
Outdated
Show resolved
Hide resolved
...rs_actions_ui/public/application/sections/rule_details/components/rule_actions_popopver.scss
Outdated
Show resolved
Hide resolved
remove checkAAD from test
mikecote
left a comment
There was a problem hiding this comment.
Tested locally and LGTM!
|
We should update the user facing docs as they are no longer correct after this PR is merged. https://www.elastic.co/guide/en/kibana/master/alerting-setup.html#alerting-authorization |
…retain-api-key � Conflicts: � x-pack/plugins/alerting/server/rules_client/rules_client.ts � x-pack/plugins/alerting/server/rules_client/tests/disable.test.ts � x-pack/plugins/alerting/server/rules_client/tests/enable.test.ts
mdefazio
left a comment
There was a problem hiding this comment.
Thanks for making those changes!
pmuellr
left a comment
There was a problem hiding this comment.
Left a question and request for some small changes
x-pack/test/alerting_api_integration/security_and_spaces/group1/tests/alerting/disable.ts
Show resolved
Hide resolved
...ck/test/alerting_api_integration/security_and_spaces/group1/tests/alerting/retain_api_key.ts
Show resolved
Hide resolved
...ck/test/alerting_api_integration/security_and_spaces/group1/tests/alerting/retain_api_key.ts
Show resolved
Hide resolved
x-pack/test/alerting_api_integration/common/fixtures/plugins/alerts/server/routes.ts
Outdated
Show resolved
Hide resolved
test apiKei is not null or undefined
💛 Build succeeded, but was flakyFailed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |

fixes: #131234
Currently we invalidate the API key when a rule is disabled and generate a new one when it is enabled again.
With this PR, we retain the API key when a rule is disabled and generate a new one just in case of the rule somehow doesn't have an API key (disabled before this feature, imported etc.)
This PR also adds an Update API Key button to rules list and rule details page to allow users to generate anew API key manually.
User interaction flow is: