Description of problem: When administrator wants to add permission for user/group, nothing happens when no user/group is selected and dialog closes. That is a little bit confusing. I suggest to add check for selected items in Administration -> Users -> Add, Permissions -> Add and similar dialogs.
Steps: 1) Go to Administration -> Users, click on Add 2) Select no user/group and click on Add 3) Check if there is any check for this situation (and you that you are still in the Add windows) Do the same steps for Permissions -> Add, Administration -> Quota -> Detail card of a quota -> Consumers tab -> Add. Result: Nothing happens, window is closed down, no message or check is shown. This is especially confusing with the Administration -> Users -> Add scenario where there are two Adds ('Add', 'Add and Close') and one of them ('Add and Close') is supposed to close the window; however, the 'Add' button closes the window too. Tested in: ovirt-engine-webadmin-portal-4.4.0-0.17.master.el7.noarch ovirt-engine-4.4.0-0.17.master.el7.noarch
Regarding patch: https://gerrit.ovirt.org/107006 After the fix generic AdElementListModel is able to disable buttons based on selection and search type. The goal is to prevent error messages by blocking invalid actions. Commands operating on selected items need to be added explicitly. Several screens have been updated: Due to bugs in selection synchronization (see below) there are still some cases where the buttons will be active. However those corner cases are covered by error handling added in other patches. Scenario 1: 1. open add dialog (Administration -> Quota -> <item> -> Permission -> Add) 2. fetch users by clicking "Go" button 3. select user A - buttons are now enabled 4. fetch users - buttons are no disabled 5. select user A - buttons are now enabled At this point table model returns 2 selected items - both being user A. 6. de-select user A - buttons are still enabled! At this point table model returns single user A. List model selection state gets overwritten which causes getSelectedItems() to return non-empty list. (note that in order to fix this behaviour it's enough to add step "3.1 de-select user A" ) Scenario 2: 1. open add dialog (Administration -> Users -> Add) 2. fetch users by clicking "Go" 3. select user A - buttons are now enabled 4. add user via "Add" button - buttons are now disabled 5. select user B - buttons are now enabled 6. deselect user B - buttons are still enabled. According to the table model user A is still selected(althoug not present in the table). Problems with selection synchronization seems to be related to 2 areas: 1. selection clearing and re-selection mechanism implemented in SearchableListModel.setItems() // SearchableListModel.setItems // protected field from super class used directly // side effects are not triggered // compare with ListModel.setSelectedItem() selectedItem = null; if (getSelectedItems() != null) { // risky getter usage - assumes that list is mutable // side effects are not triggered // compare with ListModel.setSelectedItems() getSelectedItems().clear(); } // SearchableListModel.determineSelectedItems() // assumes that either one item is selected or // multiple items are selected (mutually exclusive) // this assumption is no longer true // check ListModel.synchronizeSelection( // single-selection callback invoked // multi-select callback missing onSelectedItemChanged(); 2. synchronization of selection between table and list models implemented in EntityModelCellTable // EntityModelCellTable.java // this works only one way! // all items from table model are fetched and overwrite existing state in list model List<EntityModel> selectedItems = new ArrayList<>(); for (EntityModel entity : ((MultiSelectionModel<EntityModel>) selectionModel).getSelectedSet()) { entity.setIsSelected(true); selectedItems.add(entity); } clearCurrentSelectedItems(); getListModel().setSelectedItems(selectedItems); // HasDataListModelEditorAdapter // this works only one way! // it gets triggered by getSelectedItemChangedEvent().raise(this, EventArgs.EMPTY); // but there is no de-selecting if (list.getSelectedItems() != null) { for (Object item : list.getSelectedItems()) { T entityModel = (T) item; hasDataWidget.getSelectionModel().setSelected(entityModel, true); } }
Regarding comment 2: the patch https://gerrit.ovirt.org/#/c/107006/ has been removed from this issue.
Regarding comment 2, I have also added those two scenarios for verifying of this bug. Steps: 1) Go to Administration -> Users, click on Add 2) Select no user/group and click on Add 3) Check if there is any check for this situation (and you that you are still in the Add windows) Scenario 1: 1. open add dialog (Administration -> Quota -> <item> -> Permission -> Add) 2. fetch users by clicking "Go" button 3. select user A - buttons are now enabled 4. fetch users - buttons are no disabled 5. select user A - buttons are now enabled At this point table model returns 2 selected items - both being user A. 6. de-select user A - buttons are still enabled! 7. try to add user Scenario 2: 1. open add dialog (Administration -> Users -> Add) 2. fetch users by clicking "Go" 3. select user A - buttons are now enabled 4. add user via "Add" button - buttons are now disabled 5. select user B - buttons are now enabled 6. deselect user B 7. try to add user Results: Add and Add and close buttons are now disabled when no user or group is selected thus no need for error messages. Both added scenarios do the confusing behaviour described in the comment 2; However, they are handled by error message and do prevent unexplainable closing of the window. Verified in: ovirt-engine-4.4.0-0.26.master.el8ev.noarch ovirt-engine-webadmin-portal-4.4.0-0.26.master.el8ev.noarch
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.