When some activities are manually completed by students, some are still showing in students' timeline.
This commit fix that for module assign,chat,choice,feedback,lesson,quiz,scorm and workshop.
Namely:
- 3rd param of assertEquals() cannot be null.
- Some incorrect uses of assertNotEmpty().
- Comparing 2 strings now uses strict (===) evaluation.
Link: https://github.com/sebastianbergmann/phpunit/issues/3185
Solution here is one of:
a) Return to the previous situation, making the comparison
softer. That can achieved by forcing different types, so
float == string works.
b) Changing APIs (both forms and database return strings) to
perform some conversion to floats. That would make float
comparison (with floats or strings) to work too.
The patch here follows the a) approach. Changing all the internals
for proper float handling sounds excesive when it has been working
perfectly since ever. So we went the easier route, just getting
rid of the new === comparisons when needed by changing expectation
types to float.
There was a bug here that had not exposed until MDL-60820 introduced the
call $mform->setDefault() at the bottom of the definition_after_data()
method. That call triggers the 'updateValue' event on all form elements.
For input text elements, this effectively sets their value to the
default one, which was empty in this case due to the way how the value
had been set.
The solution here is to set the value via the same way like the normal
set_data() method does it.
The attached Behat test reproduces the problem and makes sure the patch
works.
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.
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.
John Yao