Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-1418

removeMembers redirect to main page for non-wheel user with Admin priv but not update



    • Bug
    • Resolution: Fixed
    • Minor
    • 2.3.1, 2.4.0, 2.3.0.patch
    • 2.3.0
    • UI
    • None


      When removing users using the "Remove selected members" button, the behavior is different between wheel users and non-wheel users with an admin privilege on the group. For a user that has admin privilege, but not an explicit update privilege, removing selected users will redirect the user away from the group to the site home page.

      Steps to reproduce

      1. Load the sample quick start data
      2. Log in as GrouperSystem
      3. Create Group qsuob:test:AdminAccess
      4. Don't grant anything to EveryEntity
      5. Grant admin to babe (Barry Benson)
      6. Add bawi (Barry Windsor) as member
      7. Add "babe" to the tomcat-users.xml if needed
      8. In a different browser, login as "babe"
      9. Go to qsuob:test:AdminAccess
      10. Select checkbox for Barry Windsor
      11. Click Remove Selected Members


      • Flash status "Success: removed 1 members"
      • Redirected to UiV2Main.indexMain (the home page)
      • Doesn't show change under recent activity (a separate issue?)

      Note that explicitly adding the Update privilege for the user avoids this result, and it remains on the group page.


      The source code for UiV2Group.removeMembers has this code which seems to be the immediate cause (correlated to the difference in Ajax response between wheel and admin):

            if (!group.hasUpdate(loggedInSubject) || !group.hasRead(loggedInSubject)) {
            } else {
              filterHelper(request, response, group);

      For users with the Admin privilege, privilege management in the UI shows a black checkbox for Admin, and also grey checkboxes for all the other privileges, including Read and Update. That would imply there is an inheritance of these privileges for admin. However, group.hasUpdate(loggedInSubject) and group.hasRead(loggedInSubject) are false for a user with just the Admin privilege.

      My guess for a fix is to add

      || !group.hasAdmin(loggedInSubject)

      to the conditional above. But there may be nuances in the privilege system I'm not aware of.




            chris.hyzer@at.internet2.edu Chris Hyzer
            chad.redman@at.internet2.edu Chad Redman (unc.edu)
            0 Vote for this issue
            2 Start watching this issue