No need to have a dedicated admin_setting_managewebservicetokens admin
setting subclass, and yet do not use almost any of its features. So the
patch merges the list and the forms handling into a single external
page.
Similarly, it feels like overkill to have a renderer method for a
simple confirmation widget - especially given that the URLs were
hard-coded in it. So that one was dropped.
The patch improves the display of the missing capabilities on the Manage
tokens page and the Select authorised users page. The list of
capabilities is rendered in a collapsible area and does not occupy too
much space by default.
Additionally on the later page, the patch improves the display of the
list of existing authorised users so that it respects the configured
identity fields.
The previous implementation falsely reported all implicit capabilities
inherited from the authenticated user archetype. That caused a lot of
capabilities reported as missing, even if they were correctly granted.
This new implementation uses a different logic. Instead of seeking for
explicitly assigned capabilities, it searches for capabilities that are
not assigned to any of the user's role across the system.
Please refer to the inline documentation. This should be still used for
informative reports only, not for actual permissions evaluation. The
context has been ignored here, as well as all the overrides etc. This
patch just makes it a lesser evil.
The purpose of this external function is to provide data for
asynchronous user selectors and similar widgets. It allows to search
users matching the given query in their name or other available identity
fields.
I suppose the original reasoning was that the web services protocols are
pluggable and that plugins can provide external function. But those are
not good reasons to put the whole Web services section under plugins.
Web services are not a plugin type and they always felt very
counter-intuitive there.
From the server administrtaion perspective, web services are similar to
scheduled tasks and therefore, they should live in the same section.
Manage backpacks page wasn't displaying the navigation and administration
menus when using classic theme (it's unrelated to changes done here).
This patch fixes this unexpected behaviour (raised thanks to behat tests).
Since cm_info::customdata can be of any type, we need to cast it to an
array first before checking for custom completion rules. Otherwise,
an exception can be thrown (e.g. customdata has been set as an stdClass)
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.
Use the custom completion implementation for mod_choice to test
completion_info::get_state() to cover the case where the completion
state is being determined from the custom completion condition.
* Update completion_info::get_data() to add other completion
information from a new method called get_other_cm_completion_data().
This allows the storage of the completion statuses of the following
completion rules to completion_info objects:
- 'Students must receive a grade' completion rule.
- Any custom completion rule defined by an activity.
This allows detailed completion information to be fetched for course
modules.
It also allows custom completion statuses to be cached which will help
reduce DB queries when fetching completion statuses.
* Update update_state() to fetch overall completion state from the
module's activity_custom_completion implementation. Falls back to the
*_get_completion_state() callback function.
* Update internal_set_data() to include the other cm completion data
in the updated cache data for the module instance.
Move the current logic for determining the completion status for the
"Student must receive grade" completion rule to a function so it cann
be reused.
Unit test included.
* Unit tests for completion_info::get_data() and
completion_info::internal_get_state are mocked which causes failures
with the new implementation. It's more straightforward and realistic
to generate real course and modules to test these methods.
Tests cover
- get_overall_completion_state()
- is_available()
- validate_rule()
Tests don't cover
- methods that rely on static methods such as:
- is_defined()
- static methods in the class because they can't be mocked
- abstract methods that can be tested better by the plugins
that extend activity_custom_completion such as:
- get_state()
- get_defined_custom_rules()
- get_custom_rule_descriptions()
Currently admin_setting_configselect has lazy-loading support via a
callback function (so you don't have to make pointless single-use
classes for each unusual setting), but this is not present in other
similar types.
This commit adds identical support to
admin_setting_configmulticheckbox.
