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).
All the setup/teardown/pre/post/conditions template methods
now are required to return void. This was warned with phpunit 7
and now is enforced.
At the same time, fix a few wrong function names,
provider data and param types, return statements...
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
version = planned 2015051100 release version
requires= current 2015050500 rc1 version
Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.
put descriptions in help popups instead of in table.
AMOS BEGIN
MOV [interactionscorrectcount, mod_scorm],[trackcorrectcount_help, mod_scorm]
MOV [interactionslatency, mod_scorm],[tracklatency_help, mod_scorm]
MOV [interactionsresult, mod_scorm],[trackresult_help, mod_scorm]
MOV [interactionsscoremin, mod_scorm],[trackscoremin_help, mod_scorm]
MOV [interactionsscoremax, mod_scorm],[trackscoremax_help, mod_scorm]
MOV [interactionsscoreraw, mod_scorm],[trackscoreraw_help, mod_scorm]
MOV [interactionssuspenddata, mod_scorm],[tracksuspenddata_help, mod_scorm]
MOV [interactionstime, mod_scorm],[tracktime_help, mod_scorm]
MOV [interactionsweight, mod_scorm],[trackweight_help, mod_scorm]
AMOS END
Move userreport into /report and rename parameters to be more useful
fix overcomplicated parameter handling
remove SCORM 2004 specific reporting of objectives and interactions to simplify page - these will appear in full list of tracking data instead
Also remove duplicated data - the general tracks info is repated 3 times on the page so isn't required.
remove link to player as loading scos this way is problematic
split out user tracks table into it's own file
convert tracks table to flexible table and allow export
add new interactions report
add tabs to allow navigation between reports
force wrapping of track data value even when no spaces
fix some coding guideline stuff
sam marshall