-
Bug
-
Resolution: Duplicate
-
Minor
-
None
-
2.8.8, 2.9.2
-
None
-
MOODLE_28_STABLE, MOODLE_29_STABLE
-
-
Easy
-
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.