This hack was introduced to work around a bug in MySQL 5.6.14 and
MariaDB at the time.
https://bugs.mysql.com/bug.php?id=69882
It was addressed a few months later in 5.6.16, and 5.7.4.
MariaDB merged version 5.6.16 of MySQL's InnoDB engine in MariaDB
10.0.11 and got the patch from there.
Moodle has required MySQL 5.7, and MariaDB 10.2.29 since Moodle 3.11 and
it is therefore safe to remove these hacks for these versions.
In some places we prevented cache poisoning, in others we did not. We
also did not place any restriction on the minimum value for a revision.
This change introduces a new set of functions for configonly endpoints
which validates the revision numbers passed in. If the revision is
either too old, or too new, it is rejected and the file content is not
cached. The content is still served, but caching headers are not sent,
and any local storage caching is prevented.
The current time is used as the maximum version, with 60 seconds added
to allow for any clock skew between cluster nodes. Previously some
locations used one hour, but there should never be such a large clock
skew on a correctly configured system.
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
* We need to set a different meetingID when duplicating or importing a
BigBlueButtonBN activity to prevent unwanted sharing of recordings between
meetings.
With the new flow, users can go to the login page from the confirmed page,
and if the user successfully logs in, the user will be directed to the confirmed page.
To avoid that, the confirmed page can only be seen by users who are not logged in.
The Moodle XML export of multiple choice calculated questions was
missing proper escaping of answers. Also the indentation of the
generated xml was off.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
1.9 backups used current plugin version as oldversion.
But quiz uses some hardcoded version numbers when processing
restore which is lower then current plugin number, so some quiz
logic was ignored.
See define_structure(), process_quiz_question_instance() within
restore_quiz_stepslib.php
Within the forum_get_discussion_neighbours() function of forum
when the discussions timemodified (last post) is the same, there
is a bug that does strange things when calculating the prev and
next discussions.
Note that, in real life, this is really hard to achieve, but in tests,
when multiple discussions and post can be created by generators in the
same second (specially when the test machine is quick), chances of
facing that problem are higher.
By adding 1 second wait, we ensure that the discussions won't have
the same timemodified (last post) and workaround the problem.
No mater of that, the problem deserves an issue to be created
so we guarantee from code that it also works ok when the same
timemodified (last post) situation happens.
Note that normally this doesn't matter much, but there are situations
when we want the discussion list ordering fully consistent /
deterministic.
Specifically, when discussions (or forum posts )are created in the
same second, or when the discussion titles are repeated, or 2
discussions have the same number of votes... (any criteria in general),
in the context of testing, we don't want the order
to be non-consistent, so we need to provide an extra sorting
criterion to make it fully deterministic.
So, in this case, we are adding a sort by discussion.id <<DIRECTION>>
that is an unique value, primary key... so cheap to calculate and,
that way, when the 1st sorting column has repeated values, the id
will decide.
The short name of the cc licenses are trailed with a suffix containing
the version number (current 3.0 and 4.0). The old cc* licenses become
the new cc-*-3.0 licenses and are disables, because the new cc*-4.0
licenses are the current ones.
This is a backport of MDL-43195.
when `log_out` is called from `\core\oauth2\client` it will delete the refresh token,
what it actually needs to use it to get a new access token
actually logging out is not needed here, the only thing we need to make sure is,
the invalid access token is removed from the session
that is done by storing `null`
Associate column headings of user report tables to the user ID that the
report is being generated for. This will prevent duplicate IDs for the
report columns when multiple user report tables are displayed on the
User report page.
* The table cells mentioned in the `headers` attribute of other table
cells need to be using the table header <th> tag. Otherwise, HTML
validation fails.
