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.
It was decided to roll only configuration dates and any date related to user content
such as 'timecreated' , 'timemodified' etc should not be rolled forward.
It turned out that behat's "I should see ..." does not work for buttons
rendered as `<input>` elements so this assertion worked only in Boost
where the button is rendered as `<button>` but not in Clean.
But we do not really need this check here. All we need is to make sure
that the form has been saved successfully. For which, checking for the
text on the page is enough.
p.s. Another mistake of mine to not double-check behat on both standard
themes. Sigh ...
This Behat scenario was not failing only because it actually relied on
the bug in the wrongly set accepted_types for submission attachments.
Now that the previous commit has fixed that bug, this scenario started
to fail correctly.
We need to do the same trick here as we are doing in the latter
scenario: we first upload a valid file to bypass the upload repository
checks, and rename it before submitting the form. That allows us to see
that the invalid file is caught finally.
p.s. It was a silly mistake of mine. I should had been wondering why
the same procedure worked for one field and not for the other. I would
spot the bug with wrong accepted_types earlier.
Eloy Lafuente (stronk7)