Previously, we replaced information in the same communication record
in the database, now there will be a unique record per provider.
This ensures when switching between different providers, the correct
actions such as room member management can be actioned for the correct
provider.
This also includes the required updates for the instances to no
longer assume a provider must be enabled to be relevant. Specifying a
provider is optional to fetch a specific provider instance, the default
will use the currently enabled provider.
The API was incorrectly assuming that all uses of the API were for a
course, and that the instanceid of the communication instance was a
course id. These assumptions are both entirely wrong.
The API is intended to support a range of uses including use at the
site, user, and activity levels.
Furthermore, if a group were to be used, then the instanceid should be
of that group's id, and therefore the contextid would need to be fetched
or that group's course instead.
The only solution here is to add a new contextid field to the table, and
implement it all parts of the API.
This change requires a change in the mock server which we don't have
time to do before Beta. This will be done in the coming days and this
commit content reverted.
This one will be re-introduced in MDL-79460
This change requires a change in the mock server which we don't have
time to do before Beta. This will be done in the coming days and this
commit content reverted.
This is a brand new subsystem, plugin-type, and plugin. They are written
from the ground up by us. They should not contain any coding style
violations.
This change requires a change in the mock server which we don't have
time to do before Beta. This will be done in the coming days and this
commit content reverted.
This change introduces a new API call to fetch the current power levels.
The result of this are used to fetch current admin users so as not to
remove them.
The update of existing users is simplified to only set users who do not
have the default level.
No need to sync users for role changes.
Power level changes do not need to happen after being added to a room.
They can happen in any order and persist after a user is removed.
Management fix: Although rooms and room users are implemented as
separate provider interfaces, there were still assumptions that
adding/removing rooms would require user handling. Where room_provider
was implemented but room_user_provider was not, that would then result
in either unnecessary ad-hoc tasks, or tasks failing with errors. Now,
checks are in place to avoid these scenarios.
API fix: Previously save_form_data() was being called on the old
provider instead of the newly enabled one, so when switching between
providers the settings would not be correctly applied and the provider
may not function. Now, the object is reloaded and the data is saved correctly.
Version 1.7 of the Matrix API adds a new endpoint for uploading media.
`_matrix/media/v1/create` and adds a new path parameter to the existing
`_matrix/media/v3/upload` endpoint.
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.
