Description of problem: Unassigning mail recipient for event notification is odd - This field can't be empty. I assigned 'General Host Events' events tree for notification to a mail recipient. Then I wanted to unassigned them, thus clicking on 'Manage Events' button to get 'Add Event Notification' dialog ('Add'... whatever). But there are many events assigned so instead of unselecting one by one like monkey, I did select whole parent and then unselect whole parent to have no event selected. Then I removed email from 'Mail Recipient:' field and the field got red-bordered and there's text "This field can't be empty". This is odd - IMHO it should check if any event is assigned - IT IS NOT! - and then to do check for defined value in the field. (Yes if you keep mail address in the field it would pass but IMHO this is not logical.) ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarchVersion-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. assign 'General Host Events' to a mail recipient 2. click on parent of assigned events to select all, click again to unselect all, remove mail recipient 3. click OK Actual results: field can't be empty even no event is assigned for notification Expected results: if nothing is selected don't bother with checking the field value Additional info:
Hi, Currently when the email is changed and saved in this screen, All notification are deleted and rewritten with the new email. (If it is not changed only added or deleted events are updated). So the operation of this screen is: update all notification to the form's email. allowing to update with an will make this screen inconsistent; For example lets take two cases: At Start:user configures notifications for a & b under user@localhost. Case 1) user deletes b and changes to bob@localhost - currently this will delete b and update a to bob@localhost. case 2) user only deletes b and has no email address - this might be expected to only delete b, but it is inconsistent with a... This might not be most intuitive, but it is how the screen works.
I don't like how it works now but I understand the comment #1. Anyway, I already opened a RFE for better way to assign events in the past - BZ1071197 - so I hope new way would also solve current behavior.