Red Hat Bugzilla – Bug 811639
'No users selected' error when changing the same 'Role Assignment' in two different browsers
Last modified: 2012-12-04 10:03:16 EST
Created attachment 576808 [details] no users selected error Description of problem: * Logging this issue as part of a larger discussion on page auto-refresh and behaviours when a user is logged in to the same conductor instance multiple times * If the same admin user is logged in simultaneously to two separate browsers - both pointing at the same conductor session, it is possible for that user to change a Role Assignment in one browser and then make the same change ( or a conflicting change) to the Role Assignment in the second browser. Since, by the time the change in the second browser is processed, the Role Assignment is no longer valid, Conductor returns an error. However, the error returned says "No users selected" (see attached screenshot) - which is not really the cause of the problem. Steps to Reproduce: 1. Open two separate, independent browsers pointing to the same Conductor instance 2. Log in as the same admin users in both browsers 3. In both browsers, navigate to 'Default Cloud Resource Zone" -> "Role Assignments" 4. In the first browser, change the Role Assignment of a user from "Zone User" to "Zone Administrator" 5. In the second browser, note that no update/refresh has happened since the change in step 4 above 6. In the second browser, make the same Role Assignment change - change the same user's Role Assignment to "Zone Administrator" 7. See the 'No users selected' error ( see attached screenshot) rpms tested: >> rpm -qa |grep aeolus aeolus-conductor-daemons-0.8.7-1.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch rubygem-aeolus-cli-0.3.1-1.el6.noarch aeolus-configure-2.5.2-1.el6.noarch aeolus-conductor-0.8.7-1.el6.noarch aeolus-conductor-doc-0.8.7-1.el6.noarch aeolus-all-0.8.7-1.el6.noarch
This is definitely a bug -- but I wouldn't lump it into the 'auto refresh' discussion. We should be moving away from the notion that _every page_ should auto-refresh. We should only auto-refresh pages with expected changes. This is a webapp, not a fat client. If every element of every page is auto-refreshed, we'll be making unnecessary scaling and performance problems for ourselves. Regardless of the autorefresh question, though, any web app is supposed to re-validate the assumptions embedded in the submitted form. This is why we re-check permissions on the submit that we already checked when displaying the form -- in case things changed while the user was looking at the page, we still do the right thing. What appears to be happening here is that the validation is doing the wrong thing when we get a form submission to change something to what is already its current value. It's probably saying "no users selected" because what was submitted is already what's in the database. In the case where a user _was_ selected but the admin was trying to change something to what it is already set to, we should probably just accept it and refresh the page -- possibly with a message that "this role was already $foo" rather than "this role was changed to $foo" i.e. the user got what he wanted even if we didn't have to change the db to do it.
Patch created: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-August/012151.html
Pushed to master: commit d182ba99ca7552ddf2488b478d820df7b9057694 BZ 811639 - during permission multi_update, change error message if no modifications needed And 1.1: commit 5bf2b26721169f69d16250cedd085674db927688 BZ 811639 - during permission multi_update, change error message if no modifications needed (cherry picked from commit d182ba99ca7552ddf2488b478d820df7b9057694)
Tested rpms: >> rpm -qa |grep aeolus aeolus-configure-2.8.7-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch rubygem-aeolus-cli-0.7.2-1.el6cf.noarch aeolus-conductor-0.13.14-1.el6cf.noarch aeolus-conductor-daemons-0.13.14-1.el6cf.noarch aeolus-conductor-doc-0.13.14-1.el6cf.noarch aeolus-all-0.13.14-1.el6cf.noarch Keeping two browser ( one chrome and one FF) open to the same conductor instance, with thesame admin user logging in in both, I could not make a conflicting change that was not registered as such :). See attached screenshot of the result of trying to modify the permissions of a user for whom the admin user has already revoked access in the second browser. Marking this BZ as 'verified'.
Created attachment 617189 [details] Permissions change on deleted user
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. http://rhn.redhat.com/errata/RHEA-2012-1516.html