Fetching user tours used to fail on external_api::validate_context() and
require_login() calls if the user did not have the site policy agreed.
The patch introduces a check to see if the user is fully set up and
ready to use the site before attempting to load the tours.
The simple pattern matches were conflicting in some situations. To make
this backwards compatable we need to convert it to a Regex pattern match
instead, and provide the quoted and unquoted variants.
There were two issues here:
* I am on the [categoryname] category page page (duplicated page)
* the wrong URL was being used
Since an incorrect URL was used I felt it safe to rename the step from
'category page page' to 'category page'.
This commit makes the following improvements to core page resolverss:
* allows for mixed case naming (course, Course, etc.)
* allows fields other than the idnumber to be specified:
** course: idnumber, shortname, fullname
** course category: idnumber, name
Whilst some of these fields are not unique, they will typically be
unique in most test scenarios. Where they are not then the idnumber
should be used in preference.
- This tool is only available for admins
- Before using this tool the hosting admin will need to have NPM installed and be able to run grunt
- To create the docs pages for the library run "grunt componentlibrary"
- After the pages are created the Library is available in Site adminstration > Development > UI Component Library
In order to be consistent with the majority of plugin management
pages, add the `dimmed_text` class to table rows to indicate that
a given plugin is disabled.
When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
Some fields were being hidden based on whether the service was set up
for internal service use or was a service shown on the login page.
These fields refer to OAuth 2 logins and must be configurable for both
kinds of services.
