Non-core contributed modules

Hi David,

Once those changes in MDL-19142 are committed, we're good to go with moving on this. I can try and find some time to write the backup/restore support in the subtype as well, or if you would rather (since it's your code) I'm happy to bow out and let you do it: )

Cheers
Penny

I would be very happy for you to write this code - I have not got much spare time to do this at the moment.

I'm very confused about where the student entries for the template items go. They seem to just go straight into the pdf and stay there. However, the comments from the teacher are stored in the database in their own right.

Why is this, is it because the comments are future-editable and the template items aren't?

Exactly right - students submitting work is a 'one-off' procedure: they fill in their name/initials/comments (or whatever else they were asked for) and those are then 'stamped' straight onto the PDF. (If the work is 'reverted to draft' and resubmitted, it isn't a major hassle for a student to re-enter this data, indeed incorrectly entering it is a common reason for reverting it).

Marking work may well take longer (going backwards/forwards through the pages) and possibly involve leaving off and coming back later, so the 'work in progress' annotations need to be stored in the database.

This can occasioally lead to slight problems if a student's work is 'revereted to draft' and then resubmitted by the student, after the teacher has begun commenting on it. But, I decided this was too obscure a case to worry about.

is it acceptable if only the templates that are being used by assignments in the course get backed up? i can't see a way to add non-used templates at all.

We would have to add a new top-level backup into the main course backup for them (like backup questions, for example) which I think is really out of scope.

I find it hard to imagine why someone would faff around creating a template and then not use it (the UI for creating templates is not something I am overly proud of).

I think it is acceptable to not back up unused templates.

patch for review. i've tested it and it seems to work pretty well!

ps this requires the very tip of 19_stable (i just committed a small bugfix there). i'm happy to commit this to contrib myself once you've reviewd the patch.

Sorry it's taken a few days to have a look at this.

Backup/restore of data in 'assignment_uploadpdf' table seems fine, as does the data for the templates (although there does seem to be a separate bug for me to investigate, whereby the old copy of the template is still marked as 'used for 1 assignment(s)', even after deleting the relevant assignment).

However, there does appear to be a couple of bugs in the backing up/restoring of comments.
Firstly, all the comments on the entire site are saved for each submission (rather than just the comments for that particular submission).
Secondly, when these comments are restored, they are not 'wired-up' to the correct submission (on my test server the IDs of the submissions were originally 1 and 2, after backing up, deleting and restoring from backup these IDs were now 3 and 4, but the comments were still marked as being for submissions with IDs 1 and 2).

Hope these can be fixed quick (and thanks again for taking this on). I will also need to test importing from one course to another (but will do this once the above are fixed).

Awesome, thanks for your feedback & testing.

I'll have a look at these two problems if I get some traintime tomorrow (traintime is prime programming time away from distractions!)

this patch should be applied on top of the first one, seems to fix the problem.

At a quick glance, there is one more line that needs fixing (not to say there aren't other bugs, but this is the one I've spotted):

first line of 'backup_one_submission', should look something like this:

if (!$comments = get_records('assignment_uploadpdf_comment','submission',$submission->id)) {

(rather than '... get_records('assignment_uploadpdf_comment') ...')

I may not have got that completely right (as I am writing this off the top of my head), but the original code was grabbing every uploadpdf comment in the entire site, rather than just the ones for the current submission.

Haven't had a chance to test out the other fixes (but they look good, as far as I can tell). Will test out properly later tonight, once our visitors (due any moment) have left.

sorry, for some reason that patch didn't get included in my git-format-patch even though it happened earlier.

Sorry about the delay in testing this - looks like it is working much better now - the only outstanding problem I can see is that the 'colour' of the comment is backed up, but not correctly restored - due to a typo with the UK/US spelling of 'colour/color'. If you change the line (in function 'restore_one_submission'):

$dbc->color = backup_todb($commentitei'#'['COLOUR']['0']'#');

to

$dbc->colour = backup_todb($commentitei'#'['COLOUR']['0']'#');

Then all should be well.

I am not sure about the process for you accessing the uploadpdf CVS - do you have to apply for access? can I grant it? or would it be easier for me to check in the updates?

As a New Zealander who knows how to spell correctly, I am ashamed of myself. HTML has polluted my brain.

I have access to all of moodle & contrib, I'll commit directly. Cheers!

By the way, I notice this assignment type plugin is in the main contrib tree, but not with a MOODLE_)19_STABLE tag.

It's probably a good idea to create a 1.9-tagged version at some point, since what's there with no tag is supposed to work with Moodle 2.0 and it won't because the db, file, etc APIs have all changed.

I wrote a custom questiontype recently and just put it in with MOODLE_19_STABLE tag, and no version at all in HEAD since there's not a working 2.0 version.

Thanks, I'll look up how to add tags at some point (I'm not a heavy CVS user - I am using Git for my local dev and only CVS for committing the finished updates).

same. cvs eats kittens.

committed to contrib.

Sorry to comment on such an old issue, but I realise that I have no idea how to tag my plugin with 'MOODLE_19_STABLE' or how to make sure it is not included in 'HEAD'.

Can you tell me the CVS command that will do this?

I think you probably want to follow this:
http://docs.moodle.org/en/Development:CVS_for_developers#Feature_branches_for_large_changes

Except just do it in your contrib/plugins/assignment/type/uploadpdf area.

You also probably don't need the PRE tag, but you'll need the -Rb bit.