following_should_download_between_and_bytes step sometimes
fails because of server speed. Added extended timout
ensuring they wait enough before failing.
Also, not calling force download while running behat site
following_should_download_between_and_bytes step sometimes
fails because of server speed. Added extended timout
ensuring they wait enough before failing.
Also, not calling force download while running behat site
If the download step is the last in the scenario then we
can sometimes run into the situation where the download page
causes a http redirect but behat has already conducted its
reset (generating an error). By putting a logout step we avoid
behat doing the reset until we are off that page.
Really, this is just to test the new behat setps, as much as anything.
Note that the details of what is written to the export files is tested in
the unit tests.
In order to do this in a sane way, I cleaned up a lot of old mess,
inclduing:
1. Previously, qtype_calcuated used ->answeres when importing, and
->answer when saving the form. This was crazy, so I fixed it, and
stripped out the code that made the alternative variable name work.
2. Similarly, it could handle ->answer being either an array, such as
you would get form the HTML editor, or a simple string, which is what
you get form the form. I simplified that too.
3. Finally, I made import use a transaction around saving each
question, so we don't get half questions in the database when an error
occurs.
Adds a set of options to the essay question type which implement
the following new features:
-Adds an input format which accepts only file uploads, and no
inline text.
-Adds an option to make the inline text response optional when
attachments are enabled, so students can choose to upload
an essay file.
-Adds an option to make attachments required, so essays without
attachments will be marked incomplete.
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.
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
Sadly, this involves a small API change, but I don't believe anyone was
using the argument I had to remove (because we were sometimes passing a
wrong value, and there is not way to compute the right value at that
point in the code.)
Also sadly, the code to compute the context we are importing into is now
rather spaghetti-like, but it works.
Conflicts:
question/type/upgrade.txt
There were already one just added upgrade.txt file so this ended
conflicting. Reviewed the contents, I've deleted the less detailed
note about pluginname, leaving the longer description added by Tim.
Ciao :-)
Rajesh Taneja