If you have funny combinations of JSON, JSON::XS and JSON::PP installed,
JSON can start deciding to use JSON::PP instead of JSON::XS, which equals
bad performance on very large Survey instances.
This commit adds a new warning to the Edit Survey page if JSON->backend
is detected to be something other than JSON::XS.
* Survey response startDate stored twice
startDate was being stored both in a column in Survey_response and also inside the
serialised responseJSON. Consolidated to column and moved startDate methods to
Survey.pm where they are actually used. Was not causing errors because both copies
were initialised to "now" at response creation time, and then never changed (this is also
why we don't need any repair code to fix existing survey repsonses in the wild).
* Survey ExpireIncompleteSurveyResponses Workflow Activity not enabled
The only time you'd actually want to modify startDate is when you're trying to simulate
response expiry in test code, which is why I found the above bug when I was writing the
missing test suite for ExpireIncompleteSurveyResponses. Along with test suite, added
upgrade code to enable workflow activity and add it to the Daily Maintenance Tasks
workflow. Also made minor fixes to the workflow activity, such as making sure it uses
the correct isComplete code.
* Survey::responseJSON mutator was not doing the right thing when
responseId argument was passed in
* www_viewGradeBook template fixes and documentation
content based on the separator macro, and does a best effort to fill in
tags that the splitting breaks by and start and end tags.
Update Post and Article to use it.
Also fix a bug I noticed while updating POD - when removing a
multiple-choice bundle the question should have its questionType
set to the generic "Multiple Choice' question type rather than
leaving it set to the now-deleted bundle questionType.
Have Calendar use that for determining the end of a week in viewWeek.
Fix getEventsIn to do all comparisons in UTC so that extra events are not added in.
SurveyJSON was storing a lot of redundant information (every setting on
every single section/question/answer, which, in most cases, will simply
take on the default values). This was bloating the surveyJSON property in
the db, and equally as importantly, slowing down Survey because it had to
do a lot of JSON parsing on the serialised surveyJSON object.
We now factor out and store the current section/question/answer defaults
along with the surveyJSON data itself, which means that we only needs to
store properties that differ from the defaults. This results is a massive
reduction in the size of the serialized surveyJSON stored in the database,
as well as a speed-up in json parsing time.
The compression/uncompression happens transparently to the rest of Survey.
