This has been generated running the following Sniff,
part of the Moodle's CodeSniffer standard:
- PSR2.Methods.MethodDeclaration
It just ensures all the function declarations have
the correct order for:
- abstract and final.
- visibility (public, protected, private).
- static.
So, all the lines modified by this commit are function declarations
and the only changes are in the positions of those keywords.
This commit addresses compatibility issues in the qtype_multianswer
question type. The following changes were made:
- The usage of the undeclared property $maxmark on subquestions in
qtype_multianswer was identified as problematic. To resolve this,
the existing declared property $defaultmark is now being used for
the same purpose.
By switching to the declared property $defaultmark, compatibility with
PHP 8.2 is ensured and the issue with the undeclared property is
resolved.
This fixes a regression caused by MDL-74752. If you regraded
a subsequent quiz attempt in a quiz using the 'Each attempt
builds on last' option, then the student's response could get lost.
This commit implements the necessary core hooks to ensure we only
allow a regrade of a quetion attempt to take place if the new and old
versions of the question are sufficiently similar.
It will be followed by commits to each question type where the
new method needs to be implemented.
Automated tests will be included in the first of those (mulitple choice)
becuse we need a question type that implements the hooks to test
the core changes.
This commit implements the status change pop up for a question
in the base view. This feature update will allow the change of
status of a question without creating a new version.
This commit also implements the status as a char rather than
an int value.
This commit adds the changes in questiontype base
to work with new question tables and the new structure in the
databse. Also needed for versioning.
This implementation will also introduct the question status
which allows a question to be in draft and ready status.
I also introduces changes to the base view where it shows
the latest version of the questions. The view of versions
for a question is not implemented in this commit.
This implementation will also introduce changes in the core
qtype plugins to support versioning and the changed
db schema.
Custom fields can now be added to question types.
Site administrators can configure the custom fields and
filed types available. Teachers and question creators can
then use these fields for extra question metadata when
creating questions. Question creators can control if
the fields are displayed to students when they are
taking a quiz or not.
This features uses the core Moodle custom field API.
Co-Authored-By: Matt Porritt <mattp@catalyst-au.net>
Co-Authored-By: Safat Shahin <safatshahin@catalyst-au.net>
Co-Authored-By: Marc-Alexandre Ghaly <marc-alexandreghaly@catalyst-ca.net>
This parallels question_attempt->minfraction, which allows the
fractional mark to go below zere.
This is needed to allow the certainty-base marking behaviours to work
better.
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.
When shortanswer, numerical, calculated and calculatedsimple questions
did not have a '*' match-anything answer, then any student response that
did not match any of the teacher-given answers were classified as
'[No response]', which was not right.
This patch fixes that. Such responses are now classified as
[Did not match any answer].
While I was doing this, I noticed that the display of tolerance
intervals for numerical questions in the response analysis was horrible,
so I improved it.
The most significant issue is that the HTML editor alwasy wraps <p> tags round the input, but that is not appropriate for the choices. It is especially not appropriate because we want to display the choices in a <lable> for accessibility and usability reasons. In valid HTML label can only contain inline elemnts. Therefore, I introduced a make_html_inline method, with a minimal implementation. (It could be improved in future.)
Long term, I think the best option would be a new form field type, editorinline, or something like that. That would be a smaller version of TinyMCE that only lets you enter inline elements.
Eloy Lafuente (stronk7)