Significant string changes:
* publishstate_help, core_notes - including GDPR guidance
* contactdataprotectionofficer_desc, tool_dataprivacy - removing mention
of link on privacy policy page as it is not yet implemented
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.
Allow modules to apply format_text() on user input before calling cm_info::set_content(). This is useful for
modules that add interactive content (for example, JS enhanced folder tree). Otherwise all javascript would
be removed if $CFG->forceclean is enabled.
This patch adds a check to make sure there is a converter available that
will be able to handle html->pdf conversion before adding onlinetext
submissions to the list of files to combine.
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.
