These templates are needed by plugins which use the now-deprecated
searchwidget (located in grade/amd/src/searchwidget/basewidget.js)
in order to keep that deprecated widget working during the deprecation
time period. This also clarifies the js deprecation notice.
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.
Drawers are floating elements that should cover the page content but not
the top navbar or the sticky footer. This patch gives the drawer a
consistent z-index of $zindex-fixed -1 as oposed to the $zindex-fixed
used in the rest of floating elements.
However, in mobile the drawers acts a standard web drawer, covering the
full page content, event the other floating elements. This is why in
mobile the z-index should be higher than $zindex-fixed.
This fixes a regression introduced by MDL-78324 in which the
notification was being called before the promise had resolved. This
change just reverts that.
This template shouldn't really be using string helpers inside string
helpers like it does, and this is unsupported in 4.3. This just moves
the string resolution to js land and then passes that resolved string
into the template instead.
Instead of replacing the body, revert to the desired behavior in which
the payment methods are injected into the body, retaining the desired
markup classes, etc.
Basically the changes imply that:
- For some tests that are using reflection, we need to ensure
that the backup controller is passed.
- And, whenever used explicitly in tests, it has to be destroyed.
(note that this leaves out tests running get_package(), because
that method now instantiates and destroys the controller by itself.
only tests that get a controller need to destroy it).
- Move from some old functions to the new ones introduced in the issue.
Including in this commit:
- Moved the backup controller instantiation out of the constructor
- Created a new get_backup_controller() method to retreive the controller when needed
- Removed some constructor-promoted properties
- Added resourcefilename to resource_packager constructor
- Made resource_packager to abstract class (cannot be instantiated)
- Removed constructor-promoted properties and declare them "normally"
- Backup controller is called and destroyed in get_package() method.
Only PHPUnit tests will need to play with the destroy method because
they use the reflection method
- Made course_partial_packager extend course_packager and removed constructor-promoted properties
- Removed the get_all_task_settings() method and replaced it with get_all_activity_tasks() method
- Fixed bugs related to Partial course sharing
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.
Moves the data-filtercondition property to an element that always
exists regardless of whether the selected category from the filter
has questions or not. This will effectively solve the exception
that is being thrown due to the non-existing element and also
enable creation of random questions in a category that does not
have any questions yet. Also, the data-filtercondition attribute
is no longer used when creating a random question in a new category
as this value is not relevant in this case. Instead, a default
filter condition is generated in the webservice for the random
question based on the newly created category.
