Bug 811639 - 'No users selected' error when changing the same 'Role Assignment' in two different browsers
'No users selected' error when changing the same 'Role Assignment' in two dif...
Status: CLOSED ERRATA
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Linux
unspecified Severity medium
: rc
: ---
Assigned To: Tzu-Mainn Chen
wes hayutin
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-11 11:26 EDT by Ronelle Landy
Modified: 2012-12-04 10:03 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When an user tried to modify permissions that changed in another browser, the wrong error message displayed: "No users selected" This bug fix updates the validation in permissions_controller.rb so that the appropriate error message is displayed.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 10:03:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
no users selected error (126.71 KB, image/png)
2012-04-11 11:26 EDT, Ronelle Landy
no flags Details
Permissions change on deleted user (108.46 KB, image/png)
2012-09-25 14:16 EDT, Ronelle Landy
no flags Details

  None (edit)
Description Ronelle Landy 2012-04-11 11:26:31 EDT
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
Comment 1 Scott Seago 2012-04-11 12:04:40 EDT
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.
Comment 3 Tzu-Mainn Chen 2012-08-16 16:13:51 EDT
Patch created:

http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-August/012151.html
Comment 4 Tzu-Mainn Chen 2012-08-16 16:41:28 EDT
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)
Comment 6 Ronelle Landy 2012-09-25 14:15:38 EDT
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'.
Comment 7 Ronelle Landy 2012-09-25 14:16:24 EDT
Created attachment 617189 [details]
Permissions change on deleted user
Comment 9 errata-xmlrpc 2012-12-04 10:03:16 EST
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

Note You need to log in before you can comment on or make changes to this bug.