This change moves the content of WHERE to the JOIN, thus filtering the
results before they are returned. This reduces the number of joined rows
which gives a big performance benefit.
Assessment allocation methods normally do not store any personal data.
Their duty is to create assessment records that are then exported by the
workshop core itself.
Still, some allocators (such as the Manual allocation) can store certain
personal data such as user preferences.
On low level, standard grading strategies subplugins do not store
personal themselves. They make use of the grades storage provided by
the workshop itself. What they do contain though is the information
about how the assessment forms were defined. And they are also
responsible for correctly interpreting the values in the central grades
table.
Grading strategies fulfil the contract with the parent workshop module
by implementing the workshopform_provider interface. That gives them a
chance to export data about the assessment form to each of exported
assessment.
Workshop module stores personal data in its tables, via user
preference and via core_files and core_plagiarism subsystems.
When exporting the data, we export not only data created by users
themselves (such as their submissions and provided peer-assessments) but
also all relevant data that can (or must) be used to interpret created
content and evaluate the user's performance and skills.
On the other hand, when deleting data at user's request, we delete only
those data that do not affect other users' performance evaluation. The
reasoning is that one's right for privacy does not overweight someone
else's right for fair assessment. For that reason, we can't fully delete
whole provided peer-assessments, for example. Because they are used in
cross-comparison and grading evaluation of all other peers who assessed
the same submission. So instead, we replace provided texts but still
keep the original record.
Workshop defines the interface for its grading strategy subplugins to
allow them attach personal data under their control to the exported
structures.
These tables may still contain relics of old personal data if the site
was installed before Moodle 2.0. We do not need these tables any more.
Following the "privacy by design" principles, we are dropping them now.
LTS (3.5) requires previous LTS (3.1)
This just deletes all the upgrade steps previous to 3.1.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2016052300 (v3.1.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase.
The submission viewed event was being triggered at the beginning of the
script (before doing all the validation/safety checks).
I’ve moved the triggering to a better place so the event it is only
triggered when is verified that the user has permissions to view
the submission.
Helen Foster