Ensures that the values are subsequently translated correctly. Workaround
for upstream bug: https://github.com/tinymce/tinymce/pull/9599
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
Before Moodle 4.3, config_plugins settings for qbank_columnsortorder
(disabledcol, enabledcol) had a value like
qbank_statistics\columns\facility_index,
qbank_statistics\columns\discriminative_efficiency, ...
In Moodle 4.3, the values are stored as
qbank_statistics\columns\facility_index-facility_index.
So updating the old values to match the new format.
Use the "Forum" module rather than the "Book" module, because the latter
emits two events when a student views it - if these two events happened
either side of a single second, then the report would count two distinct
views (when it was trying to assert only one).
The initial filtering for category was redundant, as it's applied
by default. While present it also caused reproducible failures on
CI due to timing issues when trying to apply multiple filters.
After discussing it in the issue, we have agreed to apply
the new phpunit_util::normalise_line_endings() method to
all the remaining cases (within tests!) where the manual
replacement was being done. This commits achieves that.
Note that I've looked for both str_replace() and preg_replace()
cases, but only the former had cases worth converting. All the
later ones are different and cannot be replaced by the new
utility method.
core_courseformat\external\get_state calls export_for_tempalte for each
course module, which in turn calls completion_info::is_tracked_user()
for the current user on the current course. The result of this call will
be the same for every course module, so does not need to be called what
may be several hundred times.
This change allows the result of is_tracked_user to be passed to the cm
state object, then calls it once and passes it to each cm's object. If
it is not passed in, it will be computed on demand as before.
Behat tests of this functionality could trigger the unlikely (in real
world usage) scenario where a user has an identical "timeaccess" value
for multiple course activities.
This led to random failures in said tests when the DB ordered items in
apparently random order, where the "timeaccess" value was equal.
