It has been detected that, right now, some localised floats are
being passed to those functions (say comma separator, say thousands)
and that's leading to all sort of problems later when comparing,
processing or storing those "wrong-floats" (user entered).
This just makes all those functions to be stricter, so any attempt
of passing to them a wrong float will fail with a clear TypeError.
Any existing case must be converted to a corrrect (X.Y) format, using
unformat_float() or PARAM_LOCALISEDFLOAT before any processing.
Localised floats cannot be used.
Also, fix all the places where those functions are called from
files having strict_types enabled because, with that, now float-like
strings are not accepted any more. Luckily, there is only case,
within the grade/classes/component_gradeitem.php file, and it has
been fixed by casting the float-like string coming from DB to float.
- Some small namespace/use/MOODLE_INTERNAL/requires reorganization.
- Move file phpdocs to class phpdocs.
- Move external method names to be new "execute" default ones.
- Move unit tests to matching core_grades\external namespace.
- Add missing clean_returnvalue() calls.
This adds a new webservice that creates gradecategories as a batch,
and deprecates the old single creation call, which is superseded.
It also patches a few small issues in the single WS, for any integrations
currently relying on that webservice.
Part of MDL-66074
This change modifies the return val for all of the grading functions to
allow them to add additional information.
This means that a grading service can suppress a Grade saved message if
there were no changes, for example.
This also adds a distinction between:
- Errored (Exception thrown in the WS call)
- Failed (Warning in the output of the WS call)
- Success (Grade actually saved)
- None of the above (No save, no fail, no change)
Eloy Lafuente (stronk7)