Storage of session metadata has moved into the session handler class.
This allows for other classes to fully control session handling and
removes the dependancy on the core sessions database table.
Previously, the standard method of interaction with the
session metadata was direct DB calls; this may break other plugins as there
are now proper APIs available through the session manager.
Co-authored-by: Darren Cocco <moodle@darren.cocco.id.au>
Co-authored-by: Trisha Milan <trishamilan@catalyst-au.net>
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
- Add SCSS code for float utility classes to the Boostrap 5 bridge SCSS file
- Replace all occurrences in the codebase (float-left > float-start, float-sm-right > float-sm-end, ...)
Standardise the same test cases, e.g. make final, covers notation,
static data providers, namespaces, etc.
Once the tests run, a couple of them failed. They required changes
to assertions to make them pass.
All setUp(), tearDown(), setUpBeforeClass() and tearDownAfterClass()
must, always, call to parent, to ensure that everything is properly
set and cleaned.
While in a lot of situations this is not needed (parents may not
have anything to run), with PHPUnit >= 10 this can become more
important because we are going to move the reset code from current
placement @ runBare() to setUp()/tearDown().
Note that all the changes performed in this commit have been detected
and fixed by moodle-cs (ParentSetUpTearDownSniffTest).
While this change is not 100% required now, it's good habit
and we are checking for it since Moodle 4.4.
All the changes in this commit have been applied automatically
using the moodle.PHPUnit.TestReturnType sniff and are, exclusively
adding the ": void" return types when missing.
Per cd85e090f3 all content was escaped, however we should only do that
when displaying the value in browser or exporting to file format which
supports HTML.
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 original implementation of group filtering introduced in MDL-80565
assumed that the log table existed in Moodle's own database. This is not
the case of the database logstore, or any similar logstore implemetning
the database \core\log\sql_reader interface.
Furthermore this check was also applying the SQL when the user had the
`accessallgroups` capability, or when the course was not in SEPARATE
groups mode (no groupmode and/or visible groups).
Co-authored: Laurent David <laurent.david@moodle.com>
