This commit brings in support for multiple versions of the Matrix
specification.
A Matrix server is compromised of a number of individually versioned API
endpoints, for example:
/_matrix/client/v3/createRoom
/_matrix/client/v3/rooms/:roomid/joined_members
/_matrix/media/v1/create
The combination of a large number of these individually versioned
endpoints forms a Matrix Specification version.
For example:
* the /_matrix/media/v1/create endpoint was created for version 1.7 of the
specification, and does not exist in earlier versions.
* in the future a new behaviour or parameter may be created for the
`createRoom` endpoint and a new endpoint created at:
/_matrix/client/v4/createRoom
A single server can support multiple versions of the Matrix
specification. The server declares the versions of the specification
that it supports using a non-versioned endpoint at
`/_matrix/client/versions`.
As a Matrix client, Moodle should:
* query the server version endpoint
* determine the combination of mutually supported Matrix specification
versions
* create a client instance of the highest-supported version of the
specification.
For example, if Moodle (Matrix client) and a remote server have the
following support:
```
Moodle: 1.1 1.2 1.3 1.4 1.5 1.6 1.7
Server: r0 1.1 1.2 1.3 1.4 1.5 1.6
```
The versions in common are 1.1 through 1.6, and version 1.6 would be
chosen.
To avoid duplication and allow for support of future features more
easily, the Moodle client is written as:
* a set of classes named `v1p1` through `v1p7` (currently) which extend
the `matrix_client` abstract class; and
* a set if PHP traits which provide the implementation for individual
versioned endpoints.
Each client version then imports any relevant traits which are present
in that version of the Matrix Specification. For example versions 1.1 to
1.6 do _not_ have the `/_matrix/media/v1/create` endpoint so they do not
import this trait. This trait was introduced in version 1.7, so the
trait is included from that version onwards.
In the future, if an endpoint is created which conflicts with an
existing endpoint, then it would be easy to create a new client version
which uses the existing common traits, and adds the new trait.
Each endpoint is written using a `command` class which extends the
Guzzle implementation of the PSR-7 Request interface. This command
class adds support for easy creation of:
* path parameters within the URI
* query parameters
* body parameters
This is done to avoid complex patterns of Request creation which are
repeated for every client endpoint.
We should always use a stored_file instance to set the avatar, and never
a data uri. Especially where the datauri is from Moodle itself.
This change requires a number of changes in associated locations.
I am not adding this change to any upgrade notes as this is a
master-only feature.
Note: I have removed some tests and will not consider fixing them
because I will be entirely removing that test file in a subsequent issue
(MDL-77917).
Otherwise the enrolment index page tries to load the course index
drawer, which doesn't exist at this point and triggers exceptions in
the editor module.
Co-authored-by: Tim Volckmann <tim.volckmann@mastersolution.com>
This commit implements the core communication api in the
core course to create or update matrix roomand its members
according to course settings. This commit will add the
communicaiton room in the course so that users can access
communication room from course.
Originally implemented as MDL-76702, MDL-76705 and MDL-76703.
Co-Authored-By: David Woloszyn <david.woloszyn@moodle.com>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
Most section related actions require the frontend to use alternative
strings depending on the format plugin lang file. This patch adds
overridden strings to the current setViewFormat course editor setup
object.
Replace the old course/dragdrop.js file (which was not even minimised)
to AMD modules and integrate them to the new reactive course editor.
From now on, a file can be drop over any course section, no matter if it
is in the course content or in the course index. It will also start
using the new process monitor to show the uploading state to the user.
The changes introduced here are completely safe, just we stop
binding SITEID and, instead, embed it in the SQL.
Why? Because Oracle 21 has started to return non-sense results
when SITEID is bound.
After lots of tests, attempts, debugging... we have been unable
to find any logic to the need of this change and also, have been
unable to reproduce the problem with a standalone script that
pretty much runs the same queries that the ones changed here.
I'm sure that there is something, somewhere, but have failed
to find it, grrr.
Please read MDL-75208 and linked issues to find more information
about this problem, that is one of the biggest mysteries I've
seen recently. Maybe at the end there is a tiny detail that
explains it all, but it's really well hidden.
When we change the position of two sections, we just need to update
the position of the affected sections, not all the sections in the course.
This will improve the performance since the system only executes the queries to affected sections.
Also, the system only clears the cache for affected sections, not all the sections in the course.
When updating/deleting a section/module, the system now only
invalidate of the element (section/module), not the whole course cache
Also, the system now only recalculate the cache for element (section/module)
if necessary, not the whole course cache
Move module/section purging to course_modinfo:
+ course_modinfo::purge_course_section_cache_by_id was created to purge section by id
+ course_modinfo::purge_course_section_cache_by_number was created to purge section by number
+ course_modinfo::purge_course_module_cache was created to purge module
The versioning changes will require some major changes
in the backup and restore of question bank and its
elements. This change introduces those changes to make
it compatible with the new world of versioning in question
bank. This commit also removes quiz_slots fields and
quiz_slot_tags table.
This commit will also introduce the versioning db
structure and some major changes to the quiz
and quiz attempts for the question, random
question and the view.
This commit implements the behat changes for versioning
in core question and associated locations.
The course_get_user_navigation_options() is called on each request
from the add_course_essentials() method, to initialise the basic
navigation options that are available or not for the current user.
This information is not always displayed in boost (for
instance, in a module page), but it might be required by some blocks,
like Navigation.
However, this block is hidden by default in boost since MDL-73347,
so at any point we should check if it's possible to change the way
this navigations options is loaded, to only get this information
when it's strictly required.
Mikel Martín