Allow registered alert types to be non-editable#65606
Allow registered alert types to be non-editable#65606YulNaumenko merged 20 commits intoelastic:masterfrom
Conversation
|
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
|
Pinging @elastic/apm-ui (Team:apm) |
|
Pinging @elastic/uptime (Team:uptime) |
x-pack/plugins/infra/public/components/alerting/logs/log_threshold_alert_type.ts
Outdated
Show resolved
Hide resolved
dgieselaar
left a comment
There was a problem hiding this comment.
LGTM @YulNaumenko! Thank you for getting a fix ready so quick 😀
...s/triggers_actions_ui/public/application/sections/alert_details/components/alert_details.tsx
Outdated
Show resolved
Hide resolved
…le-edit # 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.
…mer can display other consumers alert types, but in case if it isEditable
phillipb
left a comment
There was a problem hiding this comment.
Metrics changes look good.
rylnd
left a comment
There was a problem hiding this comment.
SIEM changes look good; I'm still able to CRUD Rule Alerts from within Detections.
I was seeing some errors when viewing Detections Rule Alerts in the Alerting UI:

It was unclear to me whether this was related to this branch, some weird local state of mine, or neither. Regardless, I was able to enable/disable the alert from the Alerting UI, albeit with multiple of those toaster errors.
@rylnd , this error message come up because siem alert types is not registered in the alerting UI registry. @mikecote are we planning to show alert details for alert types which doesn't have an alerting UI registry? |
I would say yes unless there's some technical challenges that prevent us from supporting this today. |
mikecote
left a comment
There was a problem hiding this comment.
LGTM, just a few suggestions and a comment about isEditable based on our conversation.
| iconClass: 'alert', | ||
| alertParamsExpression: IndexThresholdAlertTypeExpression, | ||
| validate: validateExpression, | ||
| requiresAppContext: true, |
There was a problem hiding this comment.
I think all the values of requiresAppContext need to be inverted now right? Since index threshold alert doesn't require app context so can be created / edited from management UIs.
…le-edit # Conflicts: # x-pack/plugins/triggers_actions_ui/public/types.ts
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert # Conflicts: # x-pack/plugins/triggers_actions_ui/public/types.ts
* Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert # Conflicts: # x-pack/plugins/triggers_actions_ui/public/types.ts # x-pack/test/alerting_api_integration/common/fixtures/plugins/alerts/server/plugin.ts
* Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert
* Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert
* Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert # Conflicts: # x-pack/plugins/triggers_actions_ui/public/types.ts # x-pack/test/alerting_api_integration/common/fixtures/plugins/alerts/server/plugin.ts
* Allow registered alert types to be non-editable (#65606) * Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert # Conflicts: # x-pack/plugins/triggers_actions_ui/public/types.ts # x-pack/test/alerting_api_integration/common/fixtures/plugins/alerts/server/plugin.ts * Fixed merge issue

Resolve #65549
In the scope of this PR:
isEditableproperty is responsible for displaying Edit button on alert details page.producerstring property, which correcpond to the application owner of the alert type.consumerand alert typeproducer. If the alertconsumerisalertingCreate Alert flyout display all alert types (not depends on theproducervalue) withisEditablesettingtrue. If alertconsumeris some other plugin(application), Create Alert flyout display only alert types with the sameproducervalue.This changes should handle mixing up alert types between plugins and hide alert types which is not ready to be created/edited from Alert Management UI.