One of the best things about working with open-source products is that when you make improvements, they benefit not only you but all users of the software.
When one of our clients has a need that requires one of their open-source tools to be modified, we encourage them to work with us to contribute that modification upstream where it can be used and maintained by the community.
In the lead-up to this month’s release of Moodle 4.1 Long-Term Support (LTS), University College London (UCL) expressed an interest in funding work to fix some issues in core Moodle code and some of the third-party plugins they rely on. Thanks to the experience and breadth of knowledge in Catalyst’s team, we were well placed to implement these changes and navigate the sometimes tricky process of contributing to a large open source project on UCL’s behalf.
As Moodle 4.1 is released this month, I wanted to share some of the contributions UCL have funded and how they will benefit the community.
Moodle 4.1
These changes are available in the new Moodle 4.1 LTS release.
MDL-55580 Process for deprecating a capability
While this may not seem like an important change for end users, this change highlights the maturity of Moodle’s codebase. Permissions in Moodle are managed by assigning capabilities such as moodle/course:view. As the requirements of the system change over time, capabilities are added, but may also change meaning or need removing.
Due to the vibrant plugin ecosystem around Moodle, it’s not safe to simply remove something like a capability from core code as this may break compatibility with existing plugins and integrations that use it. Instead, there needs to be a process whereby they can be marked as “deprecated”, showing they should no longer be used. This gives plugin maintainers time to update their code before the deprecated elements are finally removed a few releases later.
There was already a process for the deprecation of code and language strings, but not for capabilities. This addition will help keep Moodle’s codebase clean of legacy code into the future.
MDL-67020 The coursemodinfo cache item doesn’t scale when localized due to global locking
When you run Moodle at the scale required for some of our larger clients, every millisecond of performance counts. To ensure it can scale to serve the needs of the largest institutions in the world, Moodle’s Universal Cache (MUC) system allows data that is fetched regularly to be cached, reducing the load on the database and network.
UCL’s size means they run on Catalyst’s most advanced caching configuration, distributing data between servers and data centres. But a limitation in the way this cached data is calculated when the system is being accessed by lots of users resulting in poor performance and timeout errors. Working with our colleagues in Catalyst Australia, we re-architected part of the MUC system to improve performance at scale while retaining simple defaults for smaller sites.
Beyond 4.1
These contributions didn’t make it in time for the 4.1 release but were developed during the release cycle and we hope to have them included in 4.2 which is due in the summer.
LTI Improvements
UCL make heavy use of Moodle’s Learning Tools Interoperability (LTI) interface to embed internal tools in their VLE. As heavy users, they found some limitations in the way LTI tools are currently managed.
MDL-69489 Make an LTI only available to specific course categories
Moodle’s External Tool admin interface allows you to pre-configure LTI-enabled tools so they can be easily added to courses without additional configuration. But not all tools are relevant to all courses, a tool like MATLAB Grader might be useful to Maths and Science courses but not Performing Arts, for example.
With this change, we added the ability to restrict a pre-configured LTI tool to specific course categories. This means it will not be available to add to courses outside of those categories, simplifying the process for course creators.
MDL-72066 Ability to pass through specific LTI roles to tool provider
We’ve already discussed Moodle’s permissions system, but LTI-enabled tools may have their own special permissions system that applies when working in that tool.
Until now, Moodle has only identified its users as “Student”, “Instructor” or “Administrator” when they access an external tool. This change adds support for a more complete set of roles defined in the LTI specification and uses Moodle’s permission system to flexibly assign these roles to users.
MDL-72451 Show regrade error message in the quiz view page
A deceptively small error that causes big problems for big courses. Moodle’s grade book allows grade items to be defined as a calculation based on other grade items. If one of those items is deleted, it’s possible that Moodle can get “stuck” as it tries to recalculate all the course’s grades each time an activity is loaded. On big courses, this can be a long process and multiple users triggering the regrade can lead to performance problems.
Again working with our colleagues down under, we were able to implement a fix that stops the regrade being triggered after the error is first hit.
MDL-68093 Membership in some groups should be hidden from some roles
What seems like a common-sense change is never as simple as it looks from the outside. Moodle’s group system is an invaluable tool for course administration, allowing students to be divided up for activities, shown different content, given different due dates and so on. But in the modern climate where data privacy is paramount, the use of this feature can land institutions in regulatory hot water without careful attention.
Imagine you have a group of students who require an extension because a deadline falls on a religious holiday. You might call this group “Religion X”, and use this to assign a group override on due dates. But look at your course’s Participants screen, and you’ve just divulged this sensitive personal data to the whole course, in violation of the EU’s GDPR.
After an exhaustive discussion among the community to nail down the requirements we implemented new options for controlling the visibility of groups so that we can now define groups where you can only see who is in that group if you are a member yourself, or where you can see that you are in that group but you cannot see who else is a member, or where you cannot see that you are in that group at all.
This provides greater flexibility in the use of groups for advanced course administration while protecting user privacy.
Beyond Moodle core
The changes discussed above are all tracker issues that apply to Moodle’s core code. However, we’ve been working beyond that, contributing to third-party plugins that UCL relies on. Of particular note is the Sharing Cart plugin, where we have been triaging and fixing issues, and hope that our fixes will be available as part of its next release.
All Thanks to University College London
We’d like to thank UCL for working with open-source software in a way that will truly benefit the whole community.
By providing the funding to address these issues, and many more that are not mentioned here, hundreds of thousands of institutions and potentially millions of learners across the world will see a positive improvement to their experience while using Moodle 4.1.
