Some email body strings use first names as greetings,
some use full names, and some do not.
Using the first name for greeting makes it consistent and
a bit more "personal".
AMOS BEGIN
CPY [customwelcomemessage,enrol_self],[customwelcomemessage,core_enrol]
CPY [customwelcomemessage_help,enrol_self],[customwelcomemessage_help,core_enrol]
AMOS END
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
An entrypoint capability has been added that allows accessing the
upload tool. Further relevant capability checks are then performed
depending on the action being taken during the upload process.
Co-authored-by: Marina Glancy <marina@moodle.com>
The API was incorrectly assuming that all uses of the API were for a
course, and that the instanceid of the communication instance was a
course id. These assumptions are both entirely wrong.
The API is intended to support a range of uses including use at the
site, user, and activity levels.
Furthermore, if a group were to be used, then the instanceid should be
of that group's id, and therefore the contextid would need to be fetched
or that group's course instead.
The only solution here is to add a new contextid field to the table, and
implement it all parts of the API.
This commit implementes the communication api for
enrolment changes for a user, or enrolment method
and triggers the communication api update.
Originally implemented MDL-76703.
Co-authored-by: David Woloszyn <david.woloszyn@moodle.com>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
The changes introduced here are completely safe, just we stop
binding SITEID and, instead, embed it in the SQL.
Why? Because Oracle 21 has started to return non-sense results
when SITEID is bound.
After lots of tests, attempts, debugging... we have been unable
to find any logic to the need of this change and also, have been
unable to reproduce the problem with a standalone script that
pretty much runs the same queries that the ones changed here.
I'm sure that there is something, somewhere, but have failed
to find it, grrr.
Please read MDL-75208 and linked issues to find more information
about this problem, that is one of the biggest mysteries I've
seen recently. Maybe at the end there is a tiny detail that
explains it all, but it's really well hidden.
