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.
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 autocomplete AJAX is identical to the version in tool_lp, but also
includes support for excluding suggestions (i.e. cohorts already
synced with the current learning plan).
This is an update of the site registration admin page and some relevant
backend code to remove the mentions of moodle.net.
AMOS BEGIN
CPY [registerwithmoodleorg,core_admin],[registerwithmoodleorg,core_hub]
AMOS END
The template for the course competencies page expects a pluginbaseurl parameter
but the webservice that fetches when rendered by AJAX is missing this property.
Instead of showing competencies in a dialogue, give them their own full url to
display the competency in the framework it belongs to. This is useful for exported
data that won't have access to javascript.
Properly integration badges with competencies provided in Moodle.
Automatically grant the badge when the defined competencies are marked as proficient.
The add/roles thing was only converted to bootstrap 2/4 markup and the yui left in place.
The modal for adding users to a course was unsavable so I rewrote it with an mform in a popup, still calling
the same (barely) modified ajax script.
The webservice for searching cohorts was taken from admin/tool/lp and moved into /cohort. I added a generic "cohort"
mform element at the same time.
The webservice for searching for users was taken from the original ajax script.
Add special handling for text fields with the CLEANHTML type. This should
be used when students and teachers can edit the same field (you can't trust those students).
Applies cleaning on submitted data, and on data stored in the DB before it is put back in an editing form.
Helper methods (ie custom methods on a persistent) should not be callable via set() or get() even
if they start with set_ or get_. They are not the same as custom getters and setters for real persistent
properties.
While this is not related to this issue, when reviewing it was
detected that the size of those url fields was really small and
looking decided to add this bit of normalization over existing uses.
sam marshall