+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1590202 +++ ====================================================================== Description of problem: There are multiple popup coming for the event notification in RHV portal. Wen there is any event happene at that time popup will come in admin portal. Currently there is no way to disable this popups, we want feature to disable this event notification popup in RHVM portal. Version-Release number of selected component (if applicable): Red Hat Virtualization 4.2 How reproducible: 100% Steps to Reproduce: 1. If there is an event then popup will come into RHV admin portal. Actual results: Popup coming for the events as notification box in RHV portal. Expected results:- There should be some way to disable this event notification popup. Additional info:- NA. (Originally by Vaibhav Pagar)
Created attachment 1450445 [details] Hidden content on a form Here is an example of the issue. In some cases when the environment is busy there is almost no chance to remove these popups and it prevents the user from using the portal. (Originally by Roman Hodain)
Definitely an issue, and I can think of a few ways to solve from a UX perspective. Liz, can you provide your opinion? (Originally by Greg Sheremeta)
I agree with Greg, not necessarily disable completely, but do some UX magic to make it more consumable and less disturbing. (Originally by Tomas Jelinek)
Hi all, I think allowing the user to disable notifications as a feature, close all, or snooze are features that are avoiding the current problem. It would be great if we could pick up on the situations where we could let the user know in "bulk" that a number of things have happened. In this specific case, it would be really nice for the notification to be "6 VMs have been removed...". The user wouldn't feel like they've gotten a storm of notifications and it would scale to 100s of notifications if needed. Would it be technically possible to lump these together into one notification? In some cases, the application might be experiencing the same issue over and over in which case it would be great to identify if that's happening and just notify the user once rather than with multiple. (This could be a case for allowing an action of "Don't notify me again about this"). Here's an example of ManageIQ handling this situation: https://github.com/ManageIQ/manageiq-ui-service/pull/751 I think if we come across a use case where it does make sense to list out each toast notification individually, we should consider a "Clear All" feature, but it would be good to understand if there truly is a use case for this, or if we just need to be careful and considerate about which actions might cause a number of notifications at once. What do folks think? Thanks, Liz (Originally by Liz Blanchard)
(In reply to Liz from comment #5) > Hi all, > > I think allowing the user to disable notifications as a feature, close all, > or snooze are features that are avoiding the current problem. It would be > great if we could pick up on the situations where we could let the user know > in "bulk" that a number of things have happened. In this specific case, it > would be really nice for the notification to be "6 VMs have been > removed...". The user wouldn't feel like they've gotten a storm of > notifications and it would scale to 100s of notifications if needed. Would > it be technically possible to lump these together into one notification? > > In some cases, the application might be experiencing the same issue over and > over in which case it would be great to identify if that's happening and > just notify the user once rather than with multiple. (This could be a case > for allowing an action of "Don't notify me again about this"). Here's an > example of ManageIQ handling this situation: > https://github.com/ManageIQ/manageiq-ui-service/pull/751 > > I think if we come across a use case where it does make sense to list out > each toast notification individually, we should consider a "Clear All" > feature, but it would be good to understand if there truly is a use case for > this, or if we just need to be careful and considerate about which actions > might cause a number of notifications at once. > > What do folks think? > > Thanks, > Liz 1. We might need some event supression mechanism. It sometimes may not make sense to output the same / similar event to the user multiple times in succession. 2. Do events by other users pop up? 3. I wonder if we should not pop up events for items originated from the API (not sure how feasible this is!) 4. Perhaps just alerts/warnings/async tasks? (Originally by Yaniv Kaul)
@QE, to test, you'll need to do a mass operation that will cause 3 or more toast notifications to occur within 8 seconds. (Originally by Greg Sheremeta)
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.2.z': '?'}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.2.z': '?'}', ] For more info please contact: rhv-devops (Originally by rhv-bugzilla-bot)
Verified in ovirt-engine-4.2.5.2-0.1.el7ev.noarch ovirt-engine-webadmin-portal-4.2.5.2-0.1.el7ev.noarch There are now two new buttons for supression of multiple notifications: 1. Dismiss All 2. Do Not Disturb: for X minutes/hours/days / until Next Log In All of them worked as expected. One small difference between the design screenshot https://i.imgur.com/BOPonyM.png is the position of the DnD options, see my attached screenshot. The options are not located close to the DnD button but at the end of the notifications. Same in Firefox and Chrome. @Greg, is it intentional or should I file new BZ to fix the positionning?
The dropdown should appear right under the button, just like that imgur link. (I don't see another screenshot.) If you cleared your cache and you still see that, yes please file a bug :)
Created attachment 1471645 [details] Do Not Disturb - distant dropdown Right, sorry, I forgot to attach it, here it is :) Clearing the cache does not help. Filed bug 1609947.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2318