Keep source data used in import

That's an interesting idea. Which importers use QueryPath now? The QTI importer?

Many of the question interchange formats aren't DOMs. GIFT has a highly esoteric syntax. Many of the importers are made using Moodle code (and maybe soon ATutor code) which my wouldn't work with QP I think.

Maybe we can adapt QPCache to a sort of QICache (Quiz import cache)?

in IRC Sivaji pointed out the file_save_upload function. It puts uploads into a "files" table and they can be made permanent with file_set_status().

This table also records the user id of the uploader and a timestamp. This covers all the things I could think to store on the importation record, so we can just use this files table as is.

I'm going to try adding a "from_file_import" attribute to the base question type and set up the importer to store the file uploads and associate each question with its file.

So I've got the upload persisting now, but adding the "from_file" property to each question is turning out to be harder than I thought.

I'm trying to associate the record from the files table (fid) with the question node. I thought I could tack it onto the schema quiz_node_question_properties, thinking that that was common across all questions, but I've learned that it's used only by multichoice. multichoice uses that table by legacy, but each other type, using OO, has its own table.

The OO question type system has an interface for question type, but no superclass. There's no table that stores data in common among them. It would be nice to have a standard base table as long as it could be done in a non-confusing way. So I may write a superclass with properties stored in one table, and subclasses that store added properties in another. Not sure yet, just making note of the idea.

Sivaji, of course I want you and your GSoC project to succeed. I am taking pains not to impede you. Quiz is also critical to my PhD research. We can both achieve our goals without breaking each other's code.

Something very helpful in that aim is unit testing. This summer I'm working with an undergraduate here, Drew Besse, and one thing he will be doing is writing unit tests for the quiz module. He's already written tests for the import/export code and will be uploading a patch today. He's even already found a bug using the tests.

Another way to avoid breaks is by abstraction of code so changes in implementation of one part don't impact other parts. The refactorings I describe in this issue are towards that goal.

This was implemented by a patch on #515238.

It could still use error logging.

dbesse, it looks fine but it's hard to see your changes with this full new file. It can be useful to copy and edit while developing, but for patching in we need something cleaner.

Since you copied the original file, right now loading this file and the other file in the same page request will throw a fatal error because they're defining the same function names. You made questions_reimport_form() which is safe, but you didn't similarly rename questions_import_submit_moodle_format(). Because this function is exactly the same as in, questions_import.admin.inc, it should simply be included. At that point you'd encounter your name collisions with other functions that you do want to redefine, in which case you can change their names appropriately.

Once you've got the reimport file including the regular import file and calling its functions, then you can copy and rename where you want. That'll at least be a safe patch.

Once it's all working together, then we can refactor the code so that more is shared between them and it's all easier to follow. The key is to isolate concerns so the same change doesn't have to be made in multiple places (for example, when the next programmer comes around and thinks he's fixed something but there are other places the same change must be made).

dbesse, #14 is a great improvement. Here are some feedback items:

- there were some bugs with missing arguments
- $node->format is for the input format of the node, like "HTML Filter" which is 1. (not the *import* format)
- I like how you factored out common functionality. I did that a little more, abstracting db calls to the import records table
- "RIGHT JOIN" in the filename query brought up files that weren't imports. a simple "JOIN" is correct.

I fixed all the above, but there are a few remaining items before we can close this out.

The main one is, there's an if-statement on "$item_id", but that's never set. It seems that it's expected to be set when the question node already existed. That would be good, so please make that work. Also, several functions use that exact same logic, so factor that out.

Things like the input format or the taxonomic categories are specified in the import form. They're not saved for the reimportation, and they shouldn't be since an error in those may be why they're reimporting. Instead, add the Advanced fields from the normal input form into the reimport one. You might make a function in questions_import.admin.inc that returns the Advanced form field set.

Almost there.

Needs completed for alpha 3.

removed blocker tag since this is postponed.