Behaviours do not store any personal data.
Any contrib behaviour which does store personal data should utilise the
standard export interfaces as this subsystem will not call them directly.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
version = planned 2015051100 release version
requires= current 2015050500 rc1 version
Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.
This feature is designed for use on pracice or formative quizzes.
It is available for quizzes that use Interactive or Immediate feedback
behaviour.
If the teacher turns this on in the quiz settings, then once a student
has finished a question, they get a 'Redo question' button beside the
question. If they click it, then the question they finished is replaced
by a new one so they can try again to practise that particul skill or
bit of knowledge a bit more.
When randomisation is involved, the studnets will be given a question or
variant that they have not seen before if possible.
It was always a bit of a hack to use static methods on the
qbehaviour_whatever classes to return metadata about the behaviour. It
is better design to have real qbehaviour_whatever_type classes to report
that metadata, particularly now that we are planning to add more such.
For example, inheritance works better with real classes. See, for
example, the improvements in
question_engine::get_behaviour_unused_display_options().
This change has been implemented in a backwards-compatbile way. Old
behaviours will continue to work. There will just be some developer debug
output to prompt people to upgrade their code properly.
Comment format (FORMAT_...) was correctly being processed when the
manual grading happened as the result of a form submission. It was only
when done using the question_usage or question_attempt API method that
there was no way to specify the format. (Although I think the only place
this API as used was in the unit tests.)
Note that question_attempt::manual_grade API had to change, but I don't
think that is a real API change. Calling code should be using
question_usage::question_attempt, which is backwards compatible.
Note that now, if you don't pass format, then no error is generated, but
a developer debugging message is generated.
1/ type/match/tests/walkthrough_test.php - tests are failing randomly, looks like some weird randomisation is going on there - see TODOs
2/ type/multianswer/tests/upgradelibnewqe_test.php contains invalid expected value - see TODO
Eloy Lafuente (stronk7)