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.
In some cases, image might have more fields rather than the URL.
This patch is for taking them into account and displaying the image
and also these information properly.
Apart from reorganising the information displayed in the external badges
page, this information has been moved to reuse the template created in
MDL-71937, to make it easier to modify and maintain.
Apart from reorganising the information displayed in the badges page,
this information has been moved to a template in order to make it
easier to modify and maintain.
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.
This patch adds some changes to guarantee that OpenBadges 2.1 (OBv2.1)
will return always the same JSON format that OBv2.0 (because the only
difference between both versions it's the BadgeConnect API).
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
Backpack URLs (web and API) can have up to 255. However, the form
for creating/editing them, doesn't allow URLs with more than 50
characters. This patch align limitation to DB value (255).
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
The $CFG->badges_site_backpack setting has been completely removed
because it's not required anymore. From now, the primary site
backpack will be the first one in the "Manage backpacks" list (so,
the one with lower sortorder value).
Before removing $CFG->badges_site_backpack setting, admins should be
able to re-order the existing site-backpacks (because then, the first
one will be treated as the default one).
This patch adds the sort order feature to the backpack list.
High-resolution image for a badge (f3) should be sent to external
backpacks through JSON and WS methods.
Besides, when a badge is cloned, the high-resolution image should be
used to avoid the copied looks blurry.
