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.
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.
Previously, quiz statistics processing happened on a scheduled task.
This task looked for all quizzes with completed attempts, then
determined if those quizzes had a statistics calculation that's newer
than the most recent attempt, then ran the statistics calculation if
needed. It was hard coded to stop processing after 1 hour.
The queries involved in determining which quizzes needed processing
weren't terribly efficient, and combined with the 1 hour limit this made
the statistics unusable on large sites, where they are the most useful.
This converts the scheduled task to an ad-hoc task, and uses an event
observer for mod_quiz\event\attempt_submitted to queue a task when
it is needed. This removes the need for a query to work out what needs
processing, and allows the task processing to be scaled up as needed.
This new parameter / property will decide if we want to reduce
the run data before processing it:
- By default it will be disabled in table mode.
- By default it will be enabled in graph mode.
- The defaults can be changed by adding reducedata=[0|1] in the URLs
- Once data reduction is enabled, it stays enabled while
navigating within the xhprof reports.
This covers the 2 new functions with unit tests:
- xhprof_topo_sort()
- reduce_run_data()
Note that the example graph used in the provider is the
one shown in the issue to explain the reduction procedure.
Here we are reducing the xhprof runs data by removing the
__Mustache==>__Mustache calls and all the orphaned data.
To save N iterations what we are doing is:
0. The information is "topologically" sorted, so we ensure that
all the parents in the data are processed before the children.
(this will help a lot when cleaning orphaned data, see below).
1. First pass, all the candidate (by regexp) calls are removed
from the run data.
2. Second pass, all the orphaned information (calls that have
ended losing his parent) are also removed, so data is consistent.
Note that, normally we would need N passes to remove all the
orphaned data (because each pass creates new orphan candidates),
but, as far as we have ensured that the information is topologically
sorted (see point 0 above), all this can be done in one unique pass.
TODO:
- Add unit tests.
- Enable some system to be able to decide which utilities we
want to get the data reduced and which ones will continue
using the complete data. Right now the reduction is being
applied to all the utilities (both table and graph views).
- Document the change and, if implemented, the way to select
between complete/reduced data.
- Consider adding some caching to speed-up the reduction process
(some TODOs have been left in the code pointing to the critical
points).
