This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
The UX team confirmed a badge shouldn't be awarded when the criteria
use a passing grade and the user gets a failing grade.
So the COMPLETION_COMPLETE_FAIL status won't be considered
completed for activities with completion that require a passing
grade.
We cannot rely on `qualified_me()` to work reliably upon report reload
events (paging, sorting, filtering, etc. are all performed via AJAX).
Small cleanup after f0770658.
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.
The token information was not being properly cleared from the $SESSION.
As a result, certain errors were occurring when users attempted to
reconnect within the same session.
For backpack connection using OBv2.0, email and password can't be
blank.
This patch adds some extra checks to validate this and displays an
error to the users before trying to connect to the backpack.
Besides, the error displayed when any error is returned by the
backpack (like invalid credentials), has also been improved, to
make it clearer for the users.
The logic to create the issuer has been moved to the backpack form
in order to improve the workflow and update the apiBase with the
proper value comming from the badgeconnect.json manifest file.
So, as part of this change in the workflow, the following changes
has been also implemented (to make the UI easier for users):
- The "Open Badges" oAuth issuer button has been removed from the
"OAuth Services" admin page. As they are created/updated when a backpack
is saved, this button is not required anymore.
- The "OAuth2 services" and "Backpack API URL" parameters have been
removed from the Manage backpacks form, because they are created on
the fly each time the backpack is saved.
In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
The apiBase in .well-known/badgeconnect.json was ignored and it was
causing some failures when connecting or sending badges to an
external backpack.
For OBv2.1, it has been changed to always use the apiBase defined
in the badgeconnect.json backpack provider.
In MDL-77086 some extra information was added when a badge can't be
sent to a backpack. However, as the Badgr is not following the
specification, it's still hard to debug it when it fails (as
raised in MDL-75552, Badgr is not working because, in some cases,
it's returning the "Method Not Allowed / Request method 'POST'
not supported" error.
This report source differs from the original badges source (5274ee5a)
by making `user` the primary table of the report, allowing for reports
on all users regardless of whether they have been awarded badges.
Create two entities exposing reportable data on badges and their
recipients, via column and filter definitions.
Create report source bringing them together along with the user and
course entities to provide data for the reportbuilder editor.
The OBv2.0 specification includes a field "Criteria" for
BadgeClass. Until now, this field was filled using the
URL of the badge assertion, but that is causing some issues
in Badgr because it linked to the badge assertion of the
first user sending this badge to the Badgr backpack (so then,
the following users linked to the first user assertion page
too).
This patch adds a new page, badgeclass.php which will be
used from now to display any badge information which is
not related to any assertion (like happens with the criteria
in BadgeClass).
This matches it's type in the settings pages, and also the type
of the site name used as the default for the setting. It's content
will now be automatically filtered by the external exporter class.
