The mod_workshop\privacy\provider now implements the new
core_userlist_provider interface. Deleting (erasing) data follows the
same principles as in other existing methods - we do not actually delete
data that might affect other users. Instead, we only erase the sensitive
owned personal information such as provided content.
This allows the teacher to define what students are supposed to submit
(online text and/or attachment) and if the given submission part is
required or optional.
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.
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.
For consistency I renamed the old check_examples_assessed function to
check_examples_assessed_before_submission.
I also call the new function in the existing
get_workshop_access_information external function.
Increase the scope of the files that are detected and
indexed by Moodle's Global Search. This includes intro
and content areas of search areas. The use case here is
in a description for an activity there is a file added
that contains more information about the activity.
It would an advantage to be able to search this content
as well. It would also allow search engine plugins to be
able to index non text files such as images.
This was done for indicators, targets and time splitting methods so that we
can get the string identifier and component in order to display a help_icon.
The functions were also made abstract, removing the default implementation.
Indicators, targets and time splitting methods should define this function.
