This only matters in an obscure edge case, but it is an edge case we hit
with one of the OU question types.
This load data code is processing the results of a LEFT JOIN, so is_null
is the correct logic.
This affects the subquestions that appear as an embedded text input box.
There are three cases:
1. Input for subq left blank
2. Input for subq was wrong, and matched by a * wildcard.
3. Input for subq was wrong, and did not match any answer.
2. and 3. should look identical, apart from any feedback in case 2.
1. is different. The state should be displayed as "Not answered" even
though the mark for this part is still shown as 0.
There are some new unit tests for these cases.
Also, we slighly improve handling of , for decimal point in multianswer,
although there are still issues.
While working on this, I made some minor clean-ups in shortanswer and
numerical qtypes.
The problem was with the non-UTF-8-safe way that a question name
was being constructed from the question text.
I have done a proper fix with methods in the base class to
carefully construct a question name that is reasonable, and
which will fit in the database column. Then I have changed all
importers to use the new methods.
I also remembered not to break the lesson in the process.
Using consants to refer to plugin names is crazy. The whole point of
plugins is that you can install more, hence the list of constants will
never be complete.
This change introduces #### as a separator for general feedback. You need
to add ####General feedback goes here as the last thing inside the {...}.
For example
// question: 123 name: Shortanswer
::Shortanswer::Which is the best animal?{
=Frog#Good!
=%50%Cat#What is it with Moodlers and cats?
=%0%*#Completely wrong
####Here is some general feedback!
}
Note that this change is not entirely backwards compatible. It will break
any existing GIFT file where the character sequence #### us used between the
{} as part of the question. This seems highly unlikely.
In a few situations, this full stop makes things a bit more grammatical,
but there are many other situations where it causes problems. So, on
balance we will remove it.
NUMBER(X,Y) typically come back from the DB as strings. If you don't
convert them to float, then when you display them, it appears as
1.0000000, which is not normally what you want.
Also, increase the size of the field on the edit form, so if you
question does have default mark 0.1234567, you can see that!
The changes between Moodle 1.9 and 2.1 made the marking of very small
answers like 10^-20 almost impossible. This change fixes it.
This fix is almost entirely due the the careful research of Pierre
Pichet, who carefully testing various proposals, and worked out that
this one seemed best.
