* The activity information output component is still being displayed
even in the case when the activity does not have dates to show and
completion tracking is not enabled.
This also causes a horizontal line to be rendered in activity view pages
below the activity heading which does not serve much purpose when
there's no activity information to be shown.
The activity information output component should only be displayed
if there's completion information to show or if there are activty dates
to show. Otherwise, there's no need to render it.
Even if a prediction is hidden from the report once is flagged,
it can be flagged several times if the user visits detailed view via URL.
We remove the checkbox to select a prediction and flag it
once it has already been flagged.
Some of the pre-existing behat tests were creating content into the
content bank using the generator but the H5P content-type libraries
weren't uploaded.
Since MDL-69331, libraries need to be deployed previously (so fake
H5P content-type won't be displayed if these libraries don't exist).
If a H5P content-type is disabled:
- The content bank won't display existing contents having it as a
main library.
- The content bank won't allow to create new contents using it.
The addition of the activity information moves the h5p content down
out of the window view on Firefox which causes the Check button to be
unclickable. This patch increases the window size to ensure that the
check button is visible and clickable.
Credits to Eloy <stronk7@moodle.org> for the thorough investigation
of the root cause of this issue :)
The form to upload/replace files has been moved to classes/form
(it's where it should have been added when it was created).
Besides, this class has been renamed because now, with the
namespace, contentbank and form don't need to be in the name ;-)
Augument all installed plugin's security helper if there is any.
Plugins function has to be defined as plugintype_pluginname_security_helper in pluginname/lib.php file.
Some errors raised when calling external services were ignored.
Displaying this information helps to debug and find the real reasons
why some action, like connecting to an external backpack, can't be
done.
The scopes parameter should be passed when creating the OAuth2 badges
client. As it is an optional parameter, when it's empty, it will
be initilised with the supported scopes for the backpack issuer.
It will happen, for instance, when a call is done to oauth2callback.php
because, as defined in RFC6749, OAuth2 authorization response only
supports code and state.
