-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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 UI][License] Disable alert types in UI when the license doesn't support it. #85496
[Alerting UI][License] Disable alert types in UI when the license doesn't support it. #85496
Conversation
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
// .sort(([a], [b]) => | ||
// solutions ? solutions.get(a)!.localeCompare(solutions.get(b)!) : a.localeCompare(b) | ||
// ) |
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.
dead code
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.
Works well, but I'm a little worried about the maintainability of alert_type_compare.ts
.
I'd appreciate if we can rethink some of the naming in there and add unit tests around it.
alertTypeItem: AlertTypeModel; | ||
}> | ||
], | ||
solutions: Map<string, string> | undefined |
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.
It isn't quite clear what a solution is.
Is there a more descriptive name we can use here?
Additionally, can we add some unit tests around this please?
const alertTypeItemsA = a[1].find((alertTypeItem) => alertTypeItem.checkEnabledResult.isEnabled); | ||
const alertTypeItemsB = b[1].find((alertTypeItem) => alertTypeItem.checkEnabledResult.isEnabled); | ||
|
||
if (!!alertTypeItemsA && !alertTypeItemsB) { | ||
return -1; | ||
} | ||
if (!alertTypeItemsA && !!alertTypeItemsB) { | ||
return 1; | ||
} |
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.
The mix of !!
and !
makes this a little hard to follow... can we make this a little clearer?
A couple of suggestions that might help:
- Can we rename
A
andB
to something more descriptive? PerhapsAlertTypesListA
? It's common to useLeft
andRight
rather thanA
andB
. So perhapsLeftAlertTypesList
andRightAlertTypesList
? - change
alertTypeItemsA
to a more descriptive name perhaps? MaybeenabledAlertTypeInList
? - perhaps, to avoid the mix of
!!
with!
, we do something like:
const hasEnabledAlertTypeInListA = a[1].find((alertTypeItem) => alertTypeItem.checkEnabledResult.isEnabled) != undefined;
Something like that?
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 after adding the tests that @gmmorris suggested. Works as expected.
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.
Looks good. A few minor things:
-
We should have a way for the user to solve the error if they are reaching the detail view. I think if the phrase 'Please upgrade your license' is linked to the appropriate place then that solves it.
-
Ideally, I think we would show a modal warning when reaching the detail view that provides the reason for the error with the option to upgrade or delete the alert. Alternatively, we provide the context / fix for the error on the list view and not allow them to get to the detail view. As discussed, we can handle in a follow-up 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.
Added review comment about the tooltip/icon as discussed—Let's just wrap the name with the tooltip and remove the info icon.
...gins/triggers_actions_ui/public/application/sections/alerts_list/components/alerts_list.scss
Outdated
Show resolved
Hide resolved
I opened follow up issue on this. Currently not able to add a link to the error message text 'Please upgrade your license'. But instead of this I've added button |
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.
Just a small tweak to the button style...
...s/triggers_actions_ui/public/application/sections/alert_details/components/alert_details.tsx
Outdated
Show resolved
Hide resolved
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.
In the PR checklist, we have a couple a11y items in there, could you please verify them?
- Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
- Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
labelAppend={ | ||
hasDisabledByLicenseAlertTypes && ( | ||
<EuiTitle size="xxs"> | ||
<h5> |
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.
Not sure how to get all the way to this screen in the UI but an h5
strikes me as an odd choice. Do we already have an h1
- h4
on this page?
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.
Removed
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.
Geo alerts changes lgtm!
- code review
- tested locally in chrome
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
* [Alerts][License] Define minimum license required for each alert type (#84997) * Define minimum license required for each alert type * fixed typechecks * fixed tests * fixed tests * fixed due to comments * fixed due to comments * removed file * removed casting to LicenseType * [Alerts][License] Add license checks to alerts HTTP APIs and execution (#85223) * [Alerts][License] Add license checks to alerts HTTP APIs and execution * fixed typechecks * resolved conflicts * resolved conflicts * added router tests * fixed typechecks * added license check support for alert task running * fixed typechecks * added integration tests * fixed due to comments * fixed due to comments * fixed tests * fixed typechecks * [Alerting UI][License] Disable alert types in UI when the license doesn't support it. (#85496) * [Alerting UI][License] Disable alert types in UI when the license doesn't support it. * fixed typechecks * added licensing for alert list and details page * fixed multy select menu * fixed due to comments * fixed due to comments * fixed due to comments * fixed typechecks * fixed license error message * fixed license error message * fixed typechecks * fixed license error message Co-authored-by: Kibana Machine <[email protected]>
Current PR covers the licensing UI for the alert types.
The sort order is a bit more complicated then for action types, because we have groups of alert types by the solution.
Current PR implements sort order by keeping the solutions alphabet order if the solution contains at least one available alert type and if all alert types under solution is disabled by the license restriction it will be sorted after the solutions with available alert types.
Then inside the solution group we sort solution items inside by the license availability and then alphabetically by alert type name.
User still have a possibility to delete alerts with the higher order alert type license (same as for the action types).
There is a possibility to navigate to the alert details page. Should we support this?
@arisonl, @alexfrancoeur please let me know if you have any objections on the current licensing implementation.
Resolve #85496