These settings are no longer configurable on a per-instance basis, so
'delegate to teacher' needs to be removed from the options list for the
relevant fields in the tool type edit form. For existing tool types,
allow 'delegate to teacher' to continue to be used only if it's the
currently set value of these fields. If changed, it cannot be set again.
This form layout applies when adding or editing any instance which is
based on a preconfigured tool (course or site). That is now the only
supported way of configuring a mod_lti instance.
This works the same as the customclassoverride on the submit element,
in that only the 'btn' class is hard coded in the template. Passing
$options['customclassoverride'] to the constructor allows calling code
to specify other classes to be added beside 'btn'. E.g. 'btn-primary'.
If no options array is passed, 'btn-secondary' is used (the existing
class used for button elements).
Move all the logic dealing with display of the legacy instance form,
(which displays those frozen, manually-configured instances) into a
method of its own for clarity.
* In the bigbluebutton_proxy::action_url call to submodules, we need a way to get
the instance this is called upon so we can have information (parameters) for
this instance settings (like the new settings introduced by subplugins).
* Add the optional instanceid parameter in join/create/getMeetingInfo calls
Changed introduced in da2f2c9c modified various zIndex attributes for
the page drawers. This has a side-effect of breaking the user tour of
the course page for the course index.
In the Moodle additions for the Bootstrap Dropdown we update the focus
after a 50ms delay. This is presumably because the targetted focus point
may not have shown yet and may be opened in a separate thread, though
sadly the original reasoning is not documented, and is not mentioned in
the original issues.
As a result of this delay, it was possible for the user to start to
interact and then have focus stolen from them. In reality this does not
happen often - 50ms is simply too short a time for a human to do so, but
it is plenty of time for Behat to do so and we have seen some random
fails as other parts of the UI become faster. When this happens,
keyboard focus tests are broken by this 50ms behaviour.
The fix here updates the shift focus function when closing the menu to
check whether the focus has changed from the previous location already
before setting the focus.
The core/utility confirmation modal can be used in this case to confirm
backpack actions. It is not necessary to have a custom module for this
purpose.
This change includes some additional simplifications to support this
change, including conversion from done/fail to then/catch, and some
simplification of Promise usage.
There were a number of cases of nested Modal usage which have been
removed.
This commit includes some simplifications to the way in which some of
the modals are launched and allows us to remove several modules entirely
as they are no longer required following the simplification of the Modal
instantiation.
This commits adds a new static `create()` method to replace the existing
ModalFactory.create approach.
This allows the creation of a modal to now be simplified to:
```js
import SomeModalClass from 'mymodule/wherever';
// ...
const modal = await SomeModalClass.create();
```
Prior to this change the modal was instantiated via the ModalFactory,
but the Type of modal was typically pulled from the ModalClass itself
via the registry. Essentially it used to require three modules to
instantiate a single Modal, and now it takes just one.
This change moves configuration of the modal from the ModalFactory to
a new `configure` function on the Modal class which does exactly the
same thing. This means that the API is fully encapsulated within the
Modal, and an individual Modal can specify its own configuration more
easily.
This change will make it much easier to instantiate new modals,
significantly reducing boilerplate in many instances.
This change allows modals to extend the `configure()` method to provide
their own defaults, or to override standard ones.
```js
class MyModal extends Modal {
static TYPE = 'my_module/mymodal';
static TEMPLATE = 'my_module/mymodal';
configure(params = {}) {
// Override the default value for large.
params.large = true;
super.configure(params);
// Handle our own properties here.
const {
makeSound = true,
} = params;
this.setSoundEmitter(makeSound);
}
```
Prior to this change, it was common to see this happen in the _calling_
code, rather than the modal itself.
