-
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] Add licensing related enhancements of existing UI. #85640
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
@mdefazio do you have any ideas on how this modal warning should looks like? Maybe we can have some generic modal dialog for all error types (not only license error) and user will be able to see the error reason without entering the Details view? In such of case we can disable details link for the expired license alerts. |
Last week, the team discussed the new approach for UI/UX, which is to work on a proposal and then get input from the design team. I think we can try this new approach here and come up with a design. I will remove the |
@mdefazio What do you think of this?
|
Fantastic! Especially covering all errors!
The message in the modal over the details seems to duplicate what is already in the details. Seems like overkill. |
Fair point :) I used the error reason that was stored in the execution status, which is also shown in the errors details banner. If we're happy with the UX of the modal, I will work on having a better modal message. |
I was wondering why we had a modal at all. I think it's possible the details screen was empty in this case before, but now it (also) displays the error message? Seems like the transition from list -> details should either:
I was also thinking there may have been a reason we didn't want to take them to details. It's possible that we couldn't get that error message we display now, because it would have required a search through the event log, which maybe we couldn't do because of the license issue. But now we can get it, since it's in the alert? It's also possible that we could find some event log docs for the alert, before it had license issues, and so it would be a confusing experience seeing a message about the license error and some "status" on instances that looked like the alert was still running. Not sure. |
The error banner was added in the previous PR and we do have the information about the license error as part of the alert. So maybe your first option would be best where we pop up the modal but don't take them to the details page? And then if users navigate directly to the details page (through an email link or something), they would still see just the error banner. |
I think that might be potentially frustrating. If I click on an email and then see the alert detail. But then get to a different computer or later on, and I want to just review that alert detail view, I won't be able to. I tend to lean towards sending them to the alert detail and show the error banner at the top of the page instead of the popup modal. I think it's ok if instances are disabled or hidden because of license issue and we simply say that in the banner. Do we need to think of a better way to display the error message on the table view? It seems that if there are multiple instances with errors, it wouldn't make sense to try and fit that into the tooltip (Is this a possible scenario?). |
I think, today, there won't be any details available, due to things generally not operation because of the license. However, it does seem like - if that is true - we could probably change it in the future to display instance info, somehow. In that case, MikeD is correct - that would be frustrating.
In general, I'm not a fan of modals, so I'm happy with this approach as well :-) |
👍 I didn't much like the idea of having a link on the alerts list pop up a modal so I'm in agreement that it should continue to take you to the alerts details view where the error banner shows and everything is disabled.
I believe there is a single error per execution, so there should only be a single (current) error reason per alert. What if for license errrors we showed some sort of clickable error icon that (1) pops up the modal so they can choose to "Manage License" or (2) opens the license page directly without showing a modal, or something else? Just so they are able to see there's a license error and fix it without having to click into the alerts details |
What if we had small text next to the error status that said 'Fix'? (Maybe this only appears on license errors??) Clicking that opens the modal (I think it's probably good to describe what will happen as opposed to sending them to the license page). If we like this, I'm wondering if this change makes a case for moving the status to the column after the alert name. |
LGTM |
Based on the approach proposed in the issue for a handling alert execution, we should consider a UI changes, where need to provide the context / fix for the error on the list view and not allow users to get to the Detail view.
Alternatively we can 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.
The text was updated successfully, but these errors were encountered: