- When several records in {files} have the same record in {files_reference} and the synchronisation is performed, we need to update
all records in {files} so all files know if source is changed and that sync was performed;
- also when local moodle file content is changed we immediately update all files referencing to it (therefore sync of references
to the local files is unnecessary);
The expected behaviour is as follows:
* If the recently fetched data is older than 48 hours, it is considered
as outdated and the new fetch is executed
* else, if the recently fetched data is younger than 24 hours, it is
considered as fresh enough and no fetch is executed
* else, if the current time is after 01:00 AM plus a certain offset
(which is randomly generated for each site), the fetch is
executed.
Thanks to MDL-34936 and unit tests this was discovered like 2 new
places calling to get_fast_modinfo() without the sectioncache
column contents. Potential performance problem, leading to
reseting and recalculation of caches all the time.
Even in the 'Error if grade not listed case', it was applying a small
tolerance. In the case of a fuzzy match, it was returning the inexact
grade from the import file, rather than the precise grade that Moodle
was expecting.
That causes problems when the editing form is displayed, because the
value from the database does not match any of the available options, so
the grade is changed to 0%.
NUMBER(X,Y) typically come back from the DB as strings. If you don't
convert them to float, then when you display them, it appears as
1.0000000, which is not normally what you want.
Also, increase the size of the field on the edit form, so if you
question does have default mark 0.1234567, you can see that!
This adds cron code which looks for question previews that have not been
touched for more than 24 hours, and deletes them.
We try to delete previews immediately. For example if the user clicks
start again, then we immediately delete their previous preview. However,
we can't do that if they just close the preview window. Hence we need
some cron code to clean up old preview that have got left lying around.
Normally, this code will not have much to do, so it will be very fast,
so we can afford to run it every cron.
This has been implemented in such a way that in future it will be easy
to add other cron code to the question bank.
Sadly, to make this work on MySQL, we require a horrible hack in the
already hacky delete_usage_records_for_mysql function.
* Moved COURSE_DISPLAY_SINGLEPAGE and COURSE_DISPLAY_MULTIPAGE constants from courselib to moodlelib.php
* Using course display constants in course default admin setting page
This was discovered while working on MDL-32705. If some JavaScript (for
example a select all/none link) changes the state of some form fields,
then the disabledIf state of other form elements does not automatically
update.
The existing form JS was so well encapsulated that this was impossible.
This change pokes a hole in the encapsulation, and provides an API
M.form.updateFormState(formid);
that other bits of JS code can call when necessary.
