File storage conversion Quiz and Questions

This page are some notes about what has to be done for MDL-16094.

I have chosen to write this document with reference to database columns, with secondary mention of the editing forms where the value is edited. That determines what itemid should be used with each file area, but for clarity, for each file area I think we need, I have added a notation that looks like {contextid, area_name, itemid}. Well, acutally, I haven't yet, but I will.

I would like to review code changes before they are committed for all of this, but I can't see myself having time to do much work on this, only to help someone else do it.

Assumptions

I believe it is the case that each HTML editor on a form has to use a separate HTML editor (otherwise copying files to and from draft areas does not work). However, for question types, I don't think that leads to the best usability.

Similarly, each HTML editor has to have a corresponding ...format field (like questiontext, questiontextformat) even though it is stupid (from a usability point of view) for different parts of a question to use different formats.

Serving files

Files belonging to the quiz are served using the quiz_pluginfile() function and other callbacks in mod/quiz/lib.php, as for other modules. There is nothing special here.

The issue is with files belonging to questions. Doing proper access control before serving these files involves coordinating both the question type, and the activity (e.g. the quiz) that is using the questions.

Question files areas will be given names like question_xxx, or qtype_yyy_zzz, where yyy is the name of the particular question type, for example multichoice.

All questions belong to a particular context, via the link mdl_question.category -> mdl_question_categories.id, mdl_question_categories.contextid -> mdl_context.id. This is the context id that should be used for files belonging to that question.

Therefore, the URL for serving a file belonging to a question will look like one of these examples:

$CFG->wwwroot/pluginfile.php/$questioncontextid/question_generalfeeback/$attemptid/$questionid/$itemid/path/to/file.ext

$CFG->wwwroot/pluginfile.php/$questioncontextid/qtype_match_stem/$attemptid/$questionid/$itemid/path/to/file.ext

The $attemptid here is the id from the row of the mdl_question_attempts table for the quiz (or whatever) attempt that is using the question. In the question code, where we are outputting a question, the $attemptid and $questionid are normally available from the $state variable as $state->attempt and $state->question. Currently, question/preview.php does not store things in the database. It just uses the session, and a fake $attemptid of 0. That is not a problem (for us here. It is a problem in other ways.)

Therefore in pluginfile.php, we need code for any system, course category, course or module context, so that requests for files in a question_... or qtype_... file area get redirected to a question_pluginfile() function in lib/questionlib.php.

All question file areas are categories into one of three types:

'question' for ones where the file can be accessed any time the question can be seen.
'feedback' for ones where the file can be accessed only when the question feedback is visible.
'generalfeedback' for ones where the file can be accessed only when the question general feedback is visible.

(You may find that looking at the quiz_get_renderoptions function in mod/quiz/locallib.php makes this clearer.)

Therefore, we need the following function defined in the question type base class, and implemented in each question type that has its own file areas: // In the base class. function get_file_areas() {

   return array();

}
// For example, in the multichoice question type
function get_file_areas() {

   return array(
       'qtype_multichoice_correctfeedback' => 'feedback',
       'qtype_multichoice_partiallyfeedback' => 'feedback',
       'qtype_multichoice_incorrectfeedback' => 'feedback',
   );

}

So, question_pluginfile() works like this:

It inspects the end of the URL to get the $attemptid and $questionid.
Then (using $questionid to get the question type and calling $qtype->get_file_areas(), if necessary) it works out the type of file area, question, or generalfeedback.
Then it calls an appropriate ..._question_file_access() callback.
- If $attemptid is 0, it calls core_question_preview_file_access()
- Otherwise, it loads the row from mdl_question_attempts, and looks at the modulename field, and calls, typically, quiz_question_file_access().
That returns true or false, to indicate whether the file should be served.

core_question_preview_file_access needs to do an appropriate access check that matches the check at the top of question/preview.php.

quiz_question_file_access() needs to have logic similar to that on mod/quiz/attempt.php and mod/quiz/review.php. That should mostly be a case of creating an appropriate $attemptobj, and then calling the right methods.

File areas for the quiz

Quiz database structure

We need a file area for quiz.intro.

We need a file area for quiz_feedback.feedbacktext. (The overall feedback on the quiz settings form.) If it is possible to do easily, we should replace the overall feedback boxes with HTML editors (the boxes currently accept HTML input into text fields, which is functionally complete, but sucky).

We need to add a feedbacktextformat column, if it has not already been done.

Ideally, access to overall feedback files should be controlled by the same logic as whether the feedback itself is displayed. However, I think it would be acceptable to release Moodle 2.0 without this. Just leave an open tracker issue assigned to me, and I can implement that check later.

No other quiz_... tables have files associated with any columns.

File areas for questions

Question database structure

There are no fields in the 'question engine' tables that have files. Except:

There should be a question_sessions.manualcommentformat column. (But manual comment should not support attached files.)

All the issues are in the 'question bank' part, which means the core question bank, and the all the question type plugins.

Core question bank

I think that question_categories.info (which is HTML) should not have files. However, we need a question_categories.infoformat field.

We need file areas for question.questiontext and question.generalfeedback. We also need to add the missing question.generalfeedbackformat field.

We need file areas, and ...format columns for question_answers.answer and question_answers.feedback. (Depending on the question type, question_answers.answer may be HTML, or it may not, but where it is not, we will force the ...format value to something appropriate. Anyway, as an example, answers are HTML for multichoice and truefalse, but not for numerical or shortanswer.)

We must get rid of the question.image column. We need an upgrade to:
1. Do a database upgrade that appends an img tag to the questiontext, if the img column is not empty;
2. and copy the file into the right file area;
3. then drop the question.image column;
4. remove that field from all editing forms;
5. remove the places where the image is displayed.

Note that all the above changes require changes to the question editing form for all question types, but hopefully that can mostly be done in the form base class.

Question import needs to use the file-picker.

Question export should be changed to put the files in an appropriate file area. I am not sure what the best file area is right now. MDL-15573

Question types

Question types where nothing needs to be done

These only use the core question tables, or do not need files associated with their own tables.

Description
Essay
Missing type
Numerical

The new 2,0 number and unit grading use a new table question_numerical_options where the instructions field is HTML which could include images.

This table is also used by calculated and calculated simple.

Pierre Pichet 08:11, 23 May 2010 (UTC)

Random
Random short-answer matching
Short answer
True-false

Match

question_match_sub.questiontext needs a ...format column and a file area. (answertext does not. It is displayed in a select menu.)

Multiple choice

correctfeedback, partiallycorrectfeedback and incorrectfeedback all need ...format columns and a file area.

The choice entry boxes on the editing form should be changed to HTML editors.

Question types I am not really sure about

Calculated* - I don't really know what Pierre is doing here. I need to get my head round it.

So here is the status of calculated in 2,0.

The calculatedsimple is just a regular calculated that can be edited in a one page because it is not using the shared category datasets. In both on them there is no new field with image to store other than question text and answer feedback.

The answer field is just math formula i.e. plain text.

The multichoice calculated is a multichoice where calculated math formula can be inserted {=...} so the requirements are the same as regular multichoice.

Regular calculated and multichoice calculated used the new table question_calculated_options although regular calculated only used the synchronize field, multichoice calculated using the other fields. I prefer to use only one new table and the fields for multichoice calculated are a copy of most of the multichoice ones.

This is a new table in 2,0 so no file conversion.

Pierre Pichet 08:01, 23 May 2010 (UTC)

Multi-answer - probably does not need any other file areas, but the code may need fixing a bit.

So here is the status of Multi-answer in 2,0.

Multi-answer code is the same has in 1.9, the improvements has been on the data validation in the edit_form with additional warnings when the user modify the number or question type in the question text peculiarly when the question has attempts stored.

I am working on the lang strings.