The get_output_classname method is used to invoke overridden output
components from course_formats. Now the method does not accept null
output names anymore, and it controls the format class is extending
the core one.
The new course editor for Moodle 4.0 is the first AMD
module that will use the new reactive library. This
commit creates creates the initial structure of the
new course editor frontend.
Do not allow maxgrade change when some of the
users are already graded. As of now this is applicable
to the following activities:
1. Forum
2. Database
3. Lesson
4. Glossary
Signed-off-by: Sujith Haridasan <sujith@moodle.com>
This change set would bring the following new additions
to the nextcloud repo:
1. Create a new radio button in filepicker: "Link to file"
2. When user clicks this radio button a warning message
would be created, saying this file would become public.
Meaning a public link is created in the nextcloud server.
3. Created a sync_reference method to sync the files downloaded
from nextcloud server. The sync/refresh time given is 1 day/24 hours.
4. Made sure that when the file is downloaded, we use the file
from moodledata file pool.
Signed-off-by: Sujith Haridasan <sujith@moodle.com>
The new course creation for Moodle 4.0 requires to add
some leavel of reactivity to the frontend. Instead of
building a specific solution only for the course editor,
in this commit there's a generic solution that can be
used in other places in Moodle to implement single
state reactive components.
The external function 'core_user_update_users()' always returned 'null' no matter
if a user or users were successfully updated or there were some failures.
So, there was no way for the caller to know which users were updated and which were not.
After the commit changes the function returns an 'external_warnings' instance. The function uses
a delegated transaction for each user to update within a loop. This enables the function to update
as many users as possible. This differs from the previous behavior of the function when it used
a delegate transaction outside of the loop where the users were updated. This resulted in a rollback
of the whole users updating in case any of the users had some invalid data. For each user within a loop
a 'try-catch' block is used to throw exceptions which are actually returned
as warnings by the function when they are caught.
Until Moodle 4.0, renderer.php file was optional (although highly recommended)
for course formats. From Moodle 4.0 onwards, renderer is required to support
the new course editor implementation.
The legacy_format_renderer class has been created for backward compatibility,
to avoid some errors with course formats (such as social) without the renderer
file. Apart from that, course_format->get_renderer() method has been reviewed
to use this legacy_format_renderer when no renderer.php file is found.
When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
