Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[Alerting] Export rules and connectors #98802
[Alerting] Export rules and connectors #98802
Changes from 9 commits
bd1ea5c
ae7b219
6188455
0f0d65e
9b84a07
c66de1f
2621aff
df73b5f
b5e04cd
aa132b9
47ebbf5
58dfb8a
c4d4bf4
41e7e7a
6a0d61c
6d3d7ee
3be3824
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
(Referring to the
getTitle
function on top, as comments are not allowed on non-diff lines...)Ideally, we shouldn't need the object's type to be displayed in its associated title, as it introduces redundancy in some parts of the SOM UI.
Now, the main SOM table is only using an (EUI) icon to display the type associated with each object. Is there an icon associated with
rules
andconnectors
in the EUI library? If so, you could add them via themanagement.icon
property of the types.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.
@pgayvallet Discussed with @mdefazio and we currently don't have dedicated icons for
rules
orconnectors
. If we're using the default icon, should we leaveRules:
andConnectors:
in the title?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 so. This is low impact and can be changed later anyway, so I think it's fine.
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.
Thanks for being flexible. Our concern is associating icons with Rules and Connectors that may also be used elsewhere for different concepts. The viz type icons were created specifically for those types and aren't used for other things (or shouldn't be).
If we want an icon, we will just need to go the route of creating on specifically for this. However, this type column may quickly turn into a lot of different icons and likely need the title to be shown alongside them anyway.
So let's circle back to it in the future and determine if we want to only show the title.
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.
Maybe here we can replace the constants with the dynamic approach to check the action type schema?
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.
@YulNaumenko Great idea! I updated this in this commit 58dfb8a
I ran into the issue where the email and webhook secrets validation does not take into account whether
hasAuth
is set tofalse
inside the connector parameters so in this case, if the secrets validation fails, I'm still checking for the existence ofhasAuth
. Do you think that works?