Ray Morris

I'd like to get your opinions about something.  We have some code we're using locally which may be of use to others.

It seems to us it is good for data sent from a SCORM package, via SetValue(), to eventually be stored in the database so that student progress data isn't lost.  Preserving data is good, we think, even if the network connection is lost, the browser crashes, etc. a few minutes later.

Some SCORM packages don't explicitly call Commit() regularly for whatever reason.  Moodle currently doesn't commit data itself unless the SCORM package explicitly calls Commit(), so data can be lost.  We wrote some code for local use which will Commit() the data 60 seconds afer the values are set, unless the package Commit()s sooner.  

As written, it's a lot like how most OSes write data to disk, to be efficient. It calls commit only if the client (SCO) hasn't already done so explicitly, and calls it only once per 60 seconds even if many values are pending, and doesn't call it at all if no values are pending.

Would this be ueful to other people?  If so, I can re-arrange our new code in the form of a patch to scorm/datamodels/scorm_13.js.php.  The patch would basically consist of adding to SetValue():

 setAutoCommit.timeout = window.setTimeout(API_1484_11.Commit,30000, "");

But canceling that if Commit() is called explicitly:
window.clearTimeout(setAutoCommit.timeout);

Let me know what you think about adding this to the master Moodle. Currently our does some magic subclassing to alter the functionallity of the stock code without modifying the files, so I'll reformat it as a patch only if it sound slike the patch would be committed.

A new feature to do that would certaily be helpful at times. 

We had a case the other day where a SCORM activity didn't complete correctly and we would have liked to be able to manually mark it complete.  If you submit a feature request on the tracker I would vote for it.

Thank you very much, Amy.  It was clean to apply, as it looks like module.js didn't change much between that time and 2.3.2 (Build: 20120910).

If, as Dan seemed to suggest, require_login() will keep them logged in that's even better.

It solves one of the problems rather than just warning about it.

I asked if I was on the right track as far as how I was thinking of implementing a patch, but then I forgot to say what I had in mind.

My thinking, and tell me if I'm mising something, is to add a called periodically (setInterval) which would attempt to getValue().  If getValue() redirects to login, that's a timeout.  Pop up a warning dialog alond the lines of "your progress may not be saved".  

If getValue doesn't redirect but has another error, it might be good to avoid trigerring the warning due to transient network error. The warning could pop up only if getValue() failed three times.  Assuming a 20 second interval, that would mean it would have to be unresponsive for 60 seconds.  

Does that sound reasonable?  This is all assuming the earlier patch is no longer available or no longer effective for some reason.

I believe that's a setting for COURSE completion rather than ACTIVITY completion.  (They are two seperate modules.)

A course completion event signals that a student is done with the course, that they will not be doing anything further in the course.  If they unenrol, they certainly indicates they've done all they are going to do.

One reason to set a course to complete on unenrolment is to handle a type of completion event called "incomplete" , to signal the student management system that the student did not compete the course, so their transscript can be marked "I". 

In general, it just means that you don't have students listed as "in progress" forever - whoever starts a course will eventually "complete" it, succesfully or unsuccessfully.