Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-33389

Admin users don't see the groups in resources for a site they're not in the roster

    Details

    • 12 status:
      Resolved
    • 11 status:
      Resolved
    • Test Plan:
      Hide
      • Create a project site as the "instructor" user, add the Content tool
      • Add a student0001 to it as access role (can do the same in a course site, just assign as student)
      • Create a group, add this student to the group
      • Go to content,
      • Create a folder
      • On the folder click Edit Details
      • Try to "Display this folder and its contents to selected groups only." This should work and populate the group you created
      • Copy the URL of the site so you can get back to it
      • Logout and Login as admin, go to this site
      • Go to content again, Edit Details
      • Try to restrict to a group

      Expect: admin can assign to groups
      Actual: Groups list doesn't populate

      Show
      Create a project site as the "instructor" user, add the Content tool Add a student0001 to it as access role (can do the same in a course site, just assign as student) Create a group, add this student to the group Go to content, Create a folder On the folder click Edit Details Try to "Display this folder and its contents to selected groups only." This should work and populate the group you created Copy the URL of the site so you can get back to it Logout and Login as admin, go to this site Go to content again, Edit Details Try to restrict to a group Expect: admin can assign to groups Actual: Groups list doesn't populate

      Description

      What looks like another regression from SAK-32110, SAK-32103 on the isPossible method.

      If you're an admin user and go to a site where admin isn't directly in the roster that has with groups, the group dropdown in content does not populate. (See test plan)

      From what I can tell via debugging) this is because in kernel the isAllowed methods on BaseSite and BaseGroup don't do isSuperUser checks for admin so they fail. A special case for superuser could possibly be added but probably it's better to change the isPossible method to use the standard securityservice.unlock which does do these checks.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  jonespm Matthew Jones
                  Reporter:
                  jonespm Matthew Jones
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: