Currently, large courses can take a long time to perform a full regrade.
This is currently handled with a progress bar to prevent frontend
timeouts while the regrade takes place. However, because it can take so
long a teacher may not want to wait with the page open for several
minutes, particularly if they are performing several operations that
trigger a regrade.
This adds a new async flag to grade_regrade_final_grades which is true
by default. Instead of performing the regrade immediately, this queues
an instance of \core\task\regrade_final_grades for the course, which
will be executed in the background.
It is advisable to always leave the async flag set true, except in the
following scenarios:
- Automated tests.
- The regrade_final_grades task which actually wants to do the
calculations immediately.
- When you have performed a check to determine that the regrade process
is unlikely to take a long time, for example there are only a small
number of grade items.
Adding an activity with a grade item previously triggered a course
regrade, which can be extremely slow. This change makes it so that on
courses where regrading is slow, when you add an activity that
requires regrading, it takes you to an intermediate screen with a
progress bar.
This change also fixes a bug in the existing grade overview report,
which shows grades across multiple courses, but previously only
checked, and if necessary regraded, one course.
Before this change if a user used navigated to a resource activity
from another activity and then edited the settings it was likely
that using the cancel button would result in file downloading,
rather than being returned to their last page.
After this change the user will be back on the page they came from.
- changed the place where module file is included to make sure that add_moduleinfo() can be called independently from create_module()
- removed permission check from add_moduleinfo() because this function is not supposed to check permissions. Besides it's only half-check. See can_add_moduleinfo()
- added phpdocs to some functions to indicate that they can throw an exception
Function add_mod_to_section() has very confusing arguments when object looks like record from
table course_modules but field ->section refers to relative section number (course_sections.section).
In table course_modules the field section refers to course_sections.id.
Also add_mod_to_section() does not update table course_modules and does not call rebuild_course_cache()
which developer can forget to do afterwards.
- Added function course_add_cm_to_section()
- In the core code add_mod_to_section() is replaced with course_add_cm_to_section()
- Function add_mod_to_section() is deprecated
1. This used to use a complex legacy system which was buggy.
2. It now relies on a new mod/...:addinstance capability for each module.
3. All the legacy code has been stripped out.
4. Old restriction data is upgraded by creating the necessary permission
overrides. Similarly, when old backups are restored, the old settings
are converted to be overrides.
5. The required addinstance capabilities will be added as a separate
commit.
6. There is a developer debug warning about modules that are missing the
addinstance capability, unless they are MOD_ARCHETYPE_SYSTEM mods.
Mark Johnson