When navigating to the next / previous chapter, the chapter should be
the page element that gets the user's attention and focus. Its title
should be displayed at the prominent top page area without the need to
scroll to it all the time.
New functions:
* `core_user::get_profile_picture` for retrieving user picture.
* `core_user::get_profile_url` for retrieving profile url.
* `core_user::get_fullname` for retrieving user full name.
Note: the context is not used as this stage. It will be used by "User Disguises" plugin, which will be implemented later.
This commit makes the following improvements to mod_imscp tests:
* Removes unnecessary @javascript and @_file_upload tags from non-JS tests.
* Removes user/enrol data generation from tests that can be performed as admin.
* Removes "I log out" and other unnecessary steps.
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 this commit, the following improvements were made to the mod_lti Behat tests:
* Replaced manual steps with data generators to set completion.
* Eliminated unnecessary user and course enrolments data generation as some tests can be performed as an admin.
* Removed the @javascript tag from non-JS tests.
* Updated the LTI data generator to generate an internal Moodle URL in the toolurl field, enabling the use of XML files.
This feature had lots of small issues and it made sense to fix it whilst
investigating a query:
* most of the steps do not require JavaScript
* it uses the UI to set an admin setting, for every scenario:
** only 3-4 of the scenarios actually test that setting
** it is very slow to do it his way when we have a generator step we can use
* we create two assignments in the Background, but each test only uses one of them
* we create the assignments in the Background with a generator, but
update them to modify various settings in each Scenario using the UI
when we should just create one assignment for each test and set it up
correctly for that Scenario
