Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-51634

Access restrictions not working as expected.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • None
    • 2.8.8, 2.9.2
    • Groups, Restrict access
    • None
    • MOODLE_28_STABLE, MOODLE_29_STABLE
    • Hide

      Removing the moodle/course:viewhiddenactivities capability is a stopgap measure, however there are use cases where you would want users to be able to see hidden activities while still being restricted otherwise.

      Show
      Removing the moodle/course:viewhiddenactivities capability is a stopgap measure, however there are use cases where you would want users to be able to see hidden activities while still being restricted otherwise.
    • Easy
    • Hide
      1. Create a course
      2. Override the moodle/site:accessallgroups capability to prohibit for Non editing teacher at the course
      3. Create a grouping (Grouping1)
      4. Enrol a user with Non editing teacher.
      5. Create an assignment.
      6. Add a restriction so users must be a member of Grouping1
      7. Log in as the user.

      Expected: You can't interact with the activity
      Actual: You can interact with the activity.

      Show
      Create a course Override the moodle/site:accessallgroups capability to prohibit for Non editing teacher at the course Create a grouping (Grouping1) Enrol a user with Non editing teacher. Create an assignment. Add a restriction so users must be a member of Grouping1 Log in as the user. Expected: You can't interact with the activity Actual: You can interact with the activity.

      In Moodle 2.6 we had groupmemebersonly enabled, and restricted some activities to a certain grouping. Users without moodle/site:accessallgroups were correctly unable to see activities when they were not part of that grouping.

      Upon upgrading to 2.8, we've instead used the access restrictions to restrict those activities to the grouping, but those users are able to access those activities.

      Upon further investigation, this appears to be caused by the logic in update_user_visible functioning differently than how we expect it should.

      lib/modinfo.php

      // If the user cannot access the activity set the uservisible flag to false.
      // Additional checks are required to determine whether the activity is entirely hidden or just greyed out.
      if ((!$this->visible or !$this->get_available()) and
              !has_capability('moodle/course:viewhiddenactivities', $this->get_context(), $userid)) {
       
          $this->uservisible = false;
      }
      

      The code as written allows the moodle/course:viewhiddenactivities capability to override the access restrictions placed on an activity, and this is contrary to how the old groupmembersonly + grouping restriction functioned.

      Rewriting the logic thusly:

      lib/modinfo.php

      // If the user cannot access the activity set the uservisible flag to false.
      // Additional checks are required to determine whether the activity is entirely hidden or just greyed out.
      if (!$this->get_available() or (!$this->visible and
              !has_capability('moodle/course:viewhiddenactivities', $this->get_context(), $userid))) {
       
          $this->uservisible = false;
      }
      

      allows the restrictions to function as the 2.6 grouping restrictions would have.

      Even without taking into 2.6's grouping restrictions we still think this is an issue because it prevents you from restricting access to anyone with moodle/course:viewhiddenactivities.

            Unassigned Unassigned
            jmlsteele Jody Steele
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.