> On May 5, 2016, 12:57 a.m., Richard Zang wrote: > > After applying the patch. > > Created a group "mygroup", assigned role "Cluster User" to this group. > > Created user "aaa", "bbb", "ccc" and assigned all users to "mygroup" > > Changed user "aaa"'s role to Cluster Administrator. (Success) > > Changed user "aaa"'s role back to None. (Failed) > > Refresh browser aaa's role went back to Cluster User. > > Keta Patel wrote: > Hello Richard, > The behavior you see is a little different from the changes in the patch. > I receated the same groups and users as in your comment and recreated the > sequence of steps with the result as follows: > 1. Assigned "mygroup" the role "Cluster User". (attached "step1.tiff") > 2. The 3 users "aaa", "bbb", "ccc" show the "Cluster User" role in the > List View. (attached "step2.tiff") > 3. Changing the role for "aaa" to "Cluster Administrator". (attached > "step3.tiff") > 4. On clicking save button (tick mark) for "aaa", success alert message > is displayed and the role seen for "aaa" is "Cluster Administrator". > (attached "step4.tiff") > 5. Changing role for "aaa" to "None". (attached "step5.tiff") > 6. On clicking save button for "aaa", success message for "None" is seen. > Now, the effective privilege of "Cluster User" is seen for "aaa". (attached > "step6.tiff") > 7. On clicking refresh button the roles are still shown as they were in > step6. (attached "step7.tiff") > > I have tried the patch on the latest trunk code. For your reference I am > attaching the patch here again as "AMBARI-15552-May-05.patch". > Please let me know if the behavior is still inconsistent. > > Thank you, > Keta
I am sorry about the images, I didn't realize we could upload only patches on Review Board. I have added these images on the Jira AMBARI-15552. - Keta ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/46808/#review131773 ----------------------------------------------------------- On May 5, 2016, 5:59 p.m., Keta Patel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/46808/ > ----------------------------------------------------------- > > (Updated May 5, 2016, 5:59 p.m.) > > > Review request for Ambari, Di Li and Richard Zang. > > > Bugs: AMBARI-15552 > https://issues.apache.org/jira/browse/AMBARI-15552 > > > Repository: ambari > > > Description > ------- > > Reproduction Steps: > 1. Go to Admin->Manage Ambari > 2. Create a group with a few users belonging to it. > (I have created "mygroup" with "user1", "user2", "user3") > (attachments "user1.tiff", "mygroup.tiff" shows samples) > 3. Go to Clusters->Roles on the left navigation menu. > 4. The default view is the "Block" view for the roles. Assign "mygroup" a > role, say "Cluster User". > (attachment "block_view_original.tiff") > 5. Click on "List" view, it will show Users by default. It correctly shows > the role "Cluster User" for each user in "mygroup". > (attachment "list_view_users.tiff") > 6. Now, try adding a new Role, say "Service Operator", to one of the users, > say "user3". > (attachments "list_view_add_role_to_user_step1.tiff", > "list_view_add_role_to_user_step2.tiff") > 7. After making this change, the role gets added for that user (in our case > "user3"), but the roles from other users in its group gets removed. Also, the > previous role for the user ("user3") is replaced by the new Role. > (attachment "list_view_add_role_to_user_step3.tiff") > 8. You can confirm this from the the "Block" view. > (attachment "block_view_after_step3.tiff") > > So, the problem here lies with the List view where it is not able to process > the changes in the Roles correctly. A change in the Role of a user causes the > following: > > CASE-1: The displayed role (effective privilege) comes from an explicitly > assigned role to the user. > 1.1) The new selected role correctly replaces the existing privilege that was > explicitly assigned to the user. > 1.2) But if the user was assigned multiple roles explicilty (before the fix > for AMBARI-16102 got pushed in), then all the other roles, which are of lower > privilege than the role that got replaced, are still displayed in the Block > view (because those roles are still in the database). So, if the new selected > role happened to be of a lower privilege than and existing role of the user, > then even though the user sees a success Alert message, the effective > privileg he sees is different. For the Ambari user, this behavior is not > easily understandable. > > CASE-2: The displayed role (effective privilege) comes from a group the user > belongs to. > 2.1) If the new selected privilege is higher than the effective privilege > coming from the user's group(s), then the newly selected role replaces this > "group" privilege in the database, insetad of creating a new entry. > 2.2) As a result of losing the group privilege, all the group members also > lose their privileges and they show "None" as their effective privilege. > 2.3) If the newly selected privilege is lower than effective group privilege, > the Alert message shows a success of role change but the effective privilge > is still not the one that the Ambari user selected. > > > Expected results: > 1. Updating a Role of a user must replace any/all of the explicit roles it > has been assigned through the Block View. (this addresses 1.2) > Note: Even though AMBARI-16102 has attempted to fix the Block view by > allowing only a user to have just one role assigned to it, there could be > cases where the earlier version of Block view has already allowed users to > have multiple roles. So, taking this into consideration, the fix must address > removing any or all of the roles the user was assigned explicitly. > 2. Adding a Role to a user must not affect the Roles of other users in its > group. (addressing 2.1 and 2.2) > 3. Selecting a "NONE" for a user role shows the Alert "User's role chnaged to > None". This may not reflect the correct privilege status as the user might > have some effective privilege coming from its group(s). In the fix, the Alert > must show the relevant message. > 4. Alert messages must show more informative messages of what is happening > with the user's privileges and why. (addressing 1.2 and 2.3) > > > Diffs > ----- > > > ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js > 32f46c1 > > ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Cluster.js > ff388cd > > ambari-admin/src/main/resources/ui/admin-web/test/unit/controllers/clusters/UserAccessListCtrl_test.js > edf16be > > Diff: https://reviews.apache.org/r/46808/diff/ > > > Testing > ------- > > The testing done mainly checks the logic used to update the privileges of the > user/group which is done after a REST call to retrieve the privileges. > > The test cases have mocks setup for server calls. The response from the > server calls are also mocked to work with a particular set of users and > groups. > > The logic in the .then() clause following the server calls is added in the > mock promises and tweaked slightly to work locally. > > The role selection for Users is tested for: > 1. the new selected role has the same privilege as the user's effective > privilege coming from its gruop(s) > 2. the new selected role has greater privilege than the user's effective > privilege coming from its group(s) > 3. the new selected role has lower privilege tha n the user's effective > privilege coming from its group(s) > > The role selection for Groups is tested for: > 1. the new selected role has the same privilege as the group's effective > privilege. > 2. the new selected role has greater privilege than the group's effective > privilege. > 3. the new selected role has lower privilege than the group's effective > privilege. > > > File Attachments > ---------------- > > AMBARI-15552-May-05.patch > > https://reviews.apache.org/media/uploaded/files/2016/05/05/18b572fb-d55b-470a-ab3e-64fb05165e35__AMBARI-15552-May-05.patch > step1.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/d60aa005-eb44-4f38-a261-3eff93eb4ee6__step1.tiff > step2.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/e4086b36-df01-4f3a-a843-cb70e6414453__step2.tiff > step3.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/2282d477-1630-4e61-bf8b-e1458fcddf8a__step3.tiff > step4.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/f5899879-f28c-4886-96cb-e3d40a65cc02__step4.tiff > step5.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/9c79a159-8b70-4d5f-8969-3353ba668a77__step5.tiff > step6.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/d6d24e4f-f57d-40ff-bc31-31303c6c1d45__step6.tiff > step7.tiff > > https://reviews.apache.org/media/uploaded/files/2016/05/05/07b36b93-804a-494d-93e5-66b45db85023__step7.tiff > > > Thanks, > > Keta Patel > >