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.
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).
This commit addresses a number of issues with the Matrix user manager.
These are, unfortunately, tough to break out into smaller commits.
The following issues are addressed:
Matrix usernames should be kept intact in the profile field. Prior to
this change, usernames were mangled and the hostname removed entirely.
Instead the hostname was added back when it is used. This approach is
not suited to a case where a user inserts their own matrix username on a
federated server.
Unit tests should have the minimum of requirements and dependencies.
Prior to this change, unit tests were setting up an entire mock system
which was completely unnecessary. These unit tests should only test the
static methods that they claim to test, not the entire communication
subsystem, matrix API, matrix client, processors, and providers.
Matrix host names should not be curtailed. Prior to this change the
hostname of the matrix server was modified if it contained any .
characters. For example, the following changes were previously made:
| hostname | before | after |
| ------------------ | ------- | ------------------ |
| matrix.example.com | matrix | matrix.example.com |
| www.example.com | example | example.com |
I believe that the original intent was to strip the www from the front,
but this is not documented anywhere that I have found. In any case, the
username should be the completed and fully-qualified username.
Many of the methods were poorly named:
- `set_qualified_matrix_user_id` is actually a userid formatter.
This has been replaced with `get_formatted_matrix_userid`.
- `set_matrix_home_server` is actually a hostname formatter.
This has been replaced with `get_formatted_matrix_home_server`.
- `add_user_matrix_id_to_moodle` sets the matrix userid for a moodle
user, it does not add more than one.
This has been replaced with `set_matrix_userid_in_moodle`.
The `set_qualified_matrix_user_id` method was silently returning with a
false value if the profile custom field did not exist, but the
`get_matrixid_from_moodle` method was creating the profile custom field
in the same situation. These have been swapped so a set operation will
create the field if it does not exist, but a get operation will not.
This commit will implement a matrix communication plugin
to integrate matrix services with core communication.
Originally implemented as MDL-76701, MDL-76702, MDL-77357,
MDL-76705, MDL-77473 and MDL-76708.
Co-Authored-By: Stevani Andolo <stevani.andolo@moodle.com>
Co-Authored-By: David Woloszyn <david.woloszyn@moodle.com>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
This commit will implement the base api for core
communication. This will include the room creation,
room membership, room access url and all associated
api and related interfaces.
Originally implemented as MDL-76702, MDL-76703 and MDL-76705.
Co-Authored-By: David Woloszyn <david.woloszyn@moodle.com>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
