Bug 811639

Summary: 'No users selected' error when changing the same 'Role Assignment' in two different browsers
Product: [Retired] CloudForms Cloud Engine Reporter: Ronelle Landy <rlandy>
Component: aeolus-conductorAssignee: Tzu-Mainn Chen <tzumainn>
Status: CLOSED ERRATA QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, deltacloud-maint, dmacpher, hbrock, juwu, ssachdev, sseago
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
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 15:03:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
no users selected error
none
Permissions change on deleted user none

Description Ronelle Landy 2012-04-11 15:26:31 UTC 
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 16:04:40 UTC 
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 20:13:51 UTC 
Patch created:

http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-August/012151.html
Comment 4 Tzu-Mainn Chen 2012-08-16 20:41:28 UTC 
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 18:15:38 UTC 
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 18:16:24 UTC 
Created attachment 617189 [details]
Permissions change on deleted user
Comment 9 errata-xmlrpc 2012-12-04 15:03:16 UTC 
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