This commit promotes the Inplace Editable field to a first-class form
element by introducing a new partial selector for inplace editable
fields, and teaching the field manager how to recognise these, then
introducing a new field type which can handle setting values for this
field.
Behat form fields are implemented in a way completely isolated from the
rest of the Behat Context system. Whereas regular step definitions have
access to execute steps, to call `find`, check for JS running, and other
related functionality, the Moodle implementation of a field type does
not have any access to this.
By moving the core functionality of behat_base to a new trait, and the
constants to a new interface, the functionality can also be used in
behat form fields in the same way as elsewhere.
This is similar to change made in MDL-69136 to allow an already-fetched
NodeElement to be provided to the get_node_in_container() function and
makes it easier to be deterministic when writing steps.
A previous change as part of this commitset was intended to move the
modal to the document.body, but where the modal had been destroyed it
was instead added back to the body.
Before this change when a modal was shown and an element on the page
was fullscreen the modal would be created behind it.
This change ensures that the modal will be inside an element that is
fullscreen so that it will be correctly displayed.
Ensure that there is always one active element in the list of selected
autocomplete elements.
Without this we have issues beacuse clicking on the link makes the first
one active if one is not already active, and this turns a click event
into a drag event, which means that it is not deleted.
Returning a value of `false` in an event handler has the effect of
calling event.preventDefault() and event.stopPropagation().
This is neither obvious, nor desirable in this situation.
The documented values that jQuery.attr() accepts are String, Number, or
null. For some reason, when we pass a Boolean value, the subsequent
click handler does not work in some situations.
Changing this to take a Number, and unsetting it when empty, resolves
this issue.
The accessibleChange custom interaction event was only listening for
blur and focus, however some OS/browser combinations do not emit these
events until the element is explicitly blurred. This is notably
different on Firefox on some Operating Systems.
Recent changes in MDL-68167 explicitly moved the user participants page
filter module to use the accessibleChange event, which means that the
selections are now only triggered on an explicit blur when using
Firefox. This highlight a bug whereby, when the mouse is used to make a
selection, the event is not triggered until the element is blurred.
This change modifies the accessibleChange event to ignore the `change`
event where it was triggered by the keyboard and where that keybaord
event was not a [return] or [escape] keypress, but to otherwise respect
the native change event.
The `blur` event does not bubble, but the `focusout` events are not
available in all supported versions of Firefox.
Rather than switching event, this patch using event capture to
effectively achieve the same result and bubble the event up through the
DOM to the delegated listener.
There should be no functional change with this patch, except to support
Firefox fully.
version = 2020110900 release version
requires= 2020110300 current beta+ (week6roll1) version
Note that, because we are under parallel development period,
this is being done in the branch that is going to be released
(MOODLE_310_STABLE already existing) for Moodle 3.10.0 and
not in master, that is the one getting the bump under normal
(non-parallel) periods.
When 2 or more backpack were created without credentials,
a "Duplicate key value violates unique constraint" error
was raised because externalbackpackid was not taking the
correct value.
Other improvements have been done to the code too in order
to make it more readable.
Also, ensure that remove_dir() only processes directories,
because sometimes it was being called by shutdown managers
with files, leading to PHP warnings.
Co-authored-by: Eloy Lafuente (stronk7) <stronk7@moodle.org>
Co-authored-by: Jun Pataleta <jun@moodle.com>
With MariaDB 10.2.7 the driver was incorrectly returning '' (empty
string) as default for all the columns having null (meaning, no
default).
Also, cover the case in unit tests, it seems that we were already
testing other defaults but not the null case.
