XMLWordPrintable

    • MOODLE_24_STABLE
    • MOODLE_25_STABLE
    • MDL-38538_clean
    • Hide

      Some advice to help with testing this:

      A. Add

      $CFG->forced_plugin_settings = array(
          'quiz' => array('autosaveperiod' => 10),
      );
      

      in your config.php file. The shortest auto-save delay you can set in the admin settings is 60 seconds, and that is annoyingly slow. It is much easer to test at 10s.

      B. Run with the Firebug or Chrome console open (and in developer debug mode). The JavaScript outputs some useful log messages that make it clear what is going on.

      C. To make it easier to test some possible failure modes, you may want to add sleep(10); inside mod/quiz/autosave.php.

      Note that there are good unit tests for a lot of this.

      Finally, read the comment below, titled "Draft documentation" since that gives an overview of how this is supposed to work.

      Test steps (should be repeated in Firefox, Chrome, IE, Safari)

      1. Create a quiz with one of each sort of question in (within reason).

      2. Ensure that the auto-save admin setting is turned on.

      3. Attempt the quiz as a student.

      4. Do some input into one or more of the questions. After the configured delay after your first change, there should be an Ajax request to the server, to save your changes.

      5. Navigate away from the quiz by clicking the 'Home' link, and then clicking 'Leave page' in the warning dialogue. (Or, if you prefer, kill your web browser or pull the power lead out of your computer. How realistic a simulation do you want to do )

      6. Really you need to repeat 5. for each type of input (text box, HTML editor, radio button, checkbox, dropdown menu, can you be bothered to install the drag-and-drop qtype add-ons?)

      7. Navigate back to the quiz and continue attempt. Verify that the data that was autosaved is still there.

      8. Change some input again, and then click next, either before or after the autosave happens. In both cases it should just work as it has always worked before autosave was implemented.

      9. Change some data, and try to click next during the gap between the 'Doing a save' and 'Save completed' log messages. Go back to the page you were on, and verify that the outcome of that is sensible.

      10. Set a time-limit on your quiz. Wait until time has nearly expired and change something. It should not be auto-saved. (More specifically, if you set autosaveperiod to 10 seconds as recommended above, then there should be no auto-saves during the last 20 seconds.)

      11. Try to think up your own creative ways to make this break.

      12. Finally, turn off the admin setting (in config.php if that is where you turned in on). Verify that the autosave is disabled.

      Show
      Some advice to help with testing this: A. Add $CFG->forced_plugin_settings = array( 'quiz' => array('autosaveperiod' => 10), ); in your config.php file. The shortest auto-save delay you can set in the admin settings is 60 seconds, and that is annoyingly slow. It is much easer to test at 10s. B. Run with the Firebug or Chrome console open (and in developer debug mode). The JavaScript outputs some useful log messages that make it clear what is going on. C. To make it easier to test some possible failure modes, you may want to add sleep(10); inside mod/quiz/autosave.php. Note that there are good unit tests for a lot of this. Finally, read the comment below, titled "Draft documentation" since that gives an overview of how this is supposed to work. Test steps (should be repeated in Firefox, Chrome, IE, Safari) 1. Create a quiz with one of each sort of question in (within reason). 2. Ensure that the auto-save admin setting is turned on. 3. Attempt the quiz as a student. 4. Do some input into one or more of the questions. After the configured delay after your first change, there should be an Ajax request to the server, to save your changes. 5. Navigate away from the quiz by clicking the 'Home' link, and then clicking 'Leave page' in the warning dialogue. (Or, if you prefer, kill your web browser or pull the power lead out of your computer. How realistic a simulation do you want to do ) 6. Really you need to repeat 5. for each type of input (text box, HTML editor, radio button, checkbox, dropdown menu, can you be bothered to install the drag-and-drop qtype add-ons?) 7. Navigate back to the quiz and continue attempt. Verify that the data that was autosaved is still there. 8. Change some input again, and then click next, either before or after the autosave happens. In both cases it should just work as it has always worked before autosave was implemented. 9. Change some data, and try to click next during the gap between the 'Doing a save' and 'Save completed' log messages. Go back to the page you were on, and verify that the outcome of that is sensible. 10. Set a time-limit on your quiz. Wait until time has nearly expired and change something. It should not be auto-saved. (More specifically, if you set autosaveperiod to 10 seconds as recommended above, then there should be no auto-saves during the last 20 seconds.) 11. Try to think up your own creative ways to make this break. 12. Finally, turn off the admin setting (in config.php if that is where you turned in on). Verify that the autosave is disabled.

      This extends the work started in MDL-38537.

      As well as saving the data on the student's computer, we will also save it on the Moodle sever.

      Because this add extra load on the server, I think we need an option to control it, and I think this should be a site-wide admin setting

      Auto save quiz attempt data: No / Every minute / Every 2 minutes / Every 5 minutes

      When this option is on, the client-side JavaScript will automatically make an Ajax call to save the current state of the quiz attempt form with that frequency (if the student has changed any data since the last save).

      The Ajax call will go to a new script mod/quiz/autosave.php.

      This will call new code in the question engine: question_usage::auto_save(...) -> question_attempt::auto_save(...) -> question_behaviour_base::auto_save(...) which does the actual work.

      A question_attempt comprises a list of question_attempt_steps, each step has a state. During the attempt there are three states used: todo, complete and invalid. We will add a 4th state 'autosaved'. A step with that state will not be a real step, it will just hold the auto-saved data.

      We need to consider the following new cases:

      1. During an attempt which up until now has been 'normal' we get an auto-save action.
      2. With one auto-save on record, a second auto-save happens.
      3. With an auto-save on record, we then reveive a 'proper' submission, which should be processed as if the auto-saves had never happened.
      4. When displaying a quiz attempt, we find auto-save data on record which was never overwritten by a 'proper' submission.

            timhunt Tim Hunt
            timhunt Tim Hunt
            Andrew Lyons Andrew Lyons
            Dan Poltawski Dan Poltawski
            Rajesh Taneja Rajesh Taneja
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.