> On May 2, 2016, 5:28 p.m., Di Li wrote:
> > ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js,
> >  line 75
> > <https://reviews.apache.org/r/46808/diff/1/?file=1365209#file1365209line75>
> >
> >     what happens when permission_label is not None?

Hello Di,
This portion of the code where we check the permission_label "None" belongs to 
the "loadUsers()" fucntion. Whenever this function is called, we reset the 
user's/group's effective privilge. The group's "principal_type" won't get 
affected by resetting the effective privilege as it doesn't depend on member 
users for calculating the effective privilege. However, the users are affected 
by calculating the effective privilege. The "principal_type" indicates the 
source of the privileges, i.e. whether the privilege was exclusively assigned 
to the user or whether it is coming from some group the user belongs to. This 
piece of information is necessary for the latter part of the code, i.e. in the 
save() function where we check if the effecting privilege of the user coming 
from group is greater than or equal to the new privilege the Ambari user is 
attempting to assign to the user.

The reason "principal_type" is not changed for privileges other tahn "None" in 
the "loadUsers()" is beacuse the current behavior of saving the new privilege 
simply stores the selected privilege in the database after removing the 
effective privilege. There is no check made if this effective privilege is an 
exclusive user privilege or whether it belongs to some group of the user.
If the new privilege selected is other than "None", then we do not change the 
"principal_type" of the effective privilege as it would give a wrong 
information of the source.
For "None", there is no database entry from which the source is tracked, so we 
explicitly assign as "USER" or "GROUP".
Removing this check is not going to affect the behavior in save(). This change 
was made only because it is the cause of the current Jira to some extent.

- Keta

This is an automatically generated e-mail. To reply, visit:

On April 29, 2016, 12:41 a.m., Keta Patel wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46808/
> -----------------------------------------------------------
> (Updated April 29, 2016, 12:41 a.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.
> Thanks,
> Keta Patel

Reply via email to