Moodle
  1. Moodle
  2. MDL-1854

Refreshing the browser students get different random questions...

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: None
    • Component/s: Quiz
    • Labels:
      None
    • Environment:
      All
    • Database:
      Any
    • Affected Branches:
      MOODLE_14_STABLE
    • Rank:
      10393

      Description

      When a student start an attempt built with random questions, he/she can refresh the page (F5) to get different questions.

        Activity

        Hide
        Martin Dougiamas added a comment -

        From Henrik Kaipe (kaipe at users.sourceforge.net) Thursday, 2 September 2004, 10:41 PM:

        From what I know this is a truely old bug that somehow noone has reported. In the discussion below I have outlined some ideas that, when implemented, could erase this bug and also help development of some other often discussed bugs.

        http://moodle.org/mod/forum/discuss.php?d=10333

        From Eloy Lafuente (stronk7 at moodle.org) Friday, 3 September 2004, 07:15 AM:

        Yeah, the solution seems to be to create the attempt at start! Then, perhaps, if a user refresh or close the session and start a new one, then the unfinished attempt (timefinish = 0) we'll be used again for him, until the end of the days (or until he finish it).

        It will be a great improvement! and it will allow the paged quizzes popular requested feature too, cool!

        From Martin Dougiamas (martin at moodle.com) Friday, 3 September 2004, 09:52 AM:

        Somehow I missed that post of yours before, Henrik...

        Actually, I already have an implementation for the paged quizzes that this will probably not work with ...

        I'm storing all the answers in the session and then submitting at the end ... I was about to check it in.

        From Eloy Lafuente (stronk7 at moodle.org) Friday, 3 September 2004, 03:50 PM:

        Yes, my initial thought was to use sessions to store attempts and then, when it's finished, everything is sent to DB and session objets are deleted.

        But, not being sure if it's too much difficult to do it, I changed my idea from session-store to db-store to be persistent across sessions.

        Perhaps it shouldn't be stored in the mdl_attempt table, but in a special mdl_attempts_started table or something similar. It'll give us all we need to solve this bug, paged-quizzes, non-html quiz interfaces...

        Only one idea...

        From Martin Dougiamas (martin at moodle.com) Saturday, 4 September 2004, 09:53 PM:

        I've only thought about this a little, but currently the questions can put out any data they like, and collect any data they like, because attempt.php doesn't have to know about the details. The structure is stored on the web page.

        Now, to store a new attempt in an attempt_started table, does sound complex. But Henrik says This has already been prepared for during the quiz refactoring so it should not be as hard as it sounds to implement.

        Could you provide some clues as to what you meant by this, Henrik?

        From Henrik Kaipe (kaipe at users.sourceforge.net) Tuesday, 7 September 2004, 04:30 AM:

        Yes - it has already been prepared for. If you check the end of the function quiz_get_attempt_questions in lib.php there is an if-block starting with if ($attempting) {

        The $attempting boolean is true only if a quiz is attempted. Inside the block initial responses are created using the method >create_response in case none have previously been found. (For the case quiz>attemptbuildsonlast responses might have been picked from an previous attempt.) These created responses match what would be stored in quiz_responses if the student does not give any answer. This usually means an empty string but RANDOM and a few other question types differ. RANDOM differs because it also stores the question id of the actual question, which is picked by its overridden implementation of ->create_response.

        Right after the call to ->create_response I have written a remark - 'In the future...' where I suggest that the created response should be stored in quiz_responses etc. By doing this the way it is done inside the foreach-block in the function quiz_save_attempt and having the function quiz_save_attempt update the already created records instead of inserting them I believe this bug will be fixed. I have not tested it but I do have faith in my preparations.

        I noticed the bug during the refactoring and also prepared for the fix as you can see. I did not fix it because the suggested fix would make the database behave slightly differently and I didn't want the refactoring to cause any database changes.

        Sorry about the delay - I spent the weekend traveling without internet access...

        From Henrik Kaipe (kaipe at users.sourceforge.net) Thursday, 16 September 2004, 07:58 PM:

        Fixed in version 1.178 of lib.php

        I hope this works but please test it anyone...

        The solution contains a total of some 100 code lines tagged as WORKAROUND FOR QUESTION TYPE RANDOM spread out on three different places in the file. Therefore, I vote for a change of the response storage for random questions in accordance with my ideas under Have the input on one question stored by one row in quiz_responses in the discussion at http://moodle.org/mod/forum/discuss.php?d=10333

        That database change would remove all workarounds and also simplify the code for the question type RANDOM.

        From Martin Dougiamas (martin at moodle.com) Sunday, 17 October 2004, 12:11 PM:

        Hi!

        Just getting back to this ...thanks for doing that workaround, Henrik!

        I['m keen on the proper fix for this ... More here: <a href=http://moodle.org/mod/forum/discuss.php?d=10333#67331>http://moodle.org/mod/forum/discuss.php?d=10333#67331</a>

        From Timothy Takemoto (timothy at nihonbunka.com) Wednesday, 20 October 2004, 03:11 PM:

        Now that there is an attempts started table (I presume) then mdl_attempts_started table then it could also be used to create a feedback page that is in the same order as the attempt. As it stands the feedback and the attempt orders do not match when random questions are being used. This seems to be confusing my students.

        Tim

        Show
        Martin Dougiamas added a comment - From Henrik Kaipe (kaipe at users.sourceforge.net) Thursday, 2 September 2004, 10:41 PM: From what I know this is a truely old bug that somehow noone has reported. In the discussion below I have outlined some ideas that, when implemented, could erase this bug and also help development of some other often discussed bugs. http://moodle.org/mod/forum/discuss.php?d=10333 From Eloy Lafuente (stronk7 at moodle.org) Friday, 3 September 2004, 07:15 AM: Yeah, the solution seems to be to create the attempt at start! Then, perhaps, if a user refresh or close the session and start a new one, then the unfinished attempt (timefinish = 0) we'll be used again for him, until the end of the days (or until he finish it). It will be a great improvement! and it will allow the paged quizzes popular requested feature too, cool! From Martin Dougiamas (martin at moodle.com) Friday, 3 September 2004, 09:52 AM: Somehow I missed that post of yours before, Henrik... Actually, I already have an implementation for the paged quizzes that this will probably not work with ... I'm storing all the answers in the session and then submitting at the end ... I was about to check it in. From Eloy Lafuente (stronk7 at moodle.org) Friday, 3 September 2004, 03:50 PM: Yes, my initial thought was to use sessions to store attempts and then, when it's finished, everything is sent to DB and session objets are deleted. But, not being sure if it's too much difficult to do it, I changed my idea from session-store to db-store to be persistent across sessions. Perhaps it shouldn't be stored in the mdl_attempt table, but in a special mdl_attempts_started table or something similar. It'll give us all we need to solve this bug, paged-quizzes, non-html quiz interfaces... Only one idea... From Martin Dougiamas (martin at moodle.com) Saturday, 4 September 2004, 09:53 PM: I've only thought about this a little, but currently the questions can put out any data they like, and collect any data they like, because attempt.php doesn't have to know about the details. The structure is stored on the web page. Now, to store a new attempt in an attempt_started table, does sound complex. But Henrik says This has already been prepared for during the quiz refactoring so it should not be as hard as it sounds to implement. Could you provide some clues as to what you meant by this, Henrik? From Henrik Kaipe (kaipe at users.sourceforge.net) Tuesday, 7 September 2004, 04:30 AM: Yes - it has already been prepared for. If you check the end of the function quiz_get_attempt_questions in lib.php there is an if-block starting with if ($attempting) { The $attempting boolean is true only if a quiz is attempted. Inside the block initial responses are created using the method >create_response in case none have previously been found. (For the case quiz >attemptbuildsonlast responses might have been picked from an previous attempt.) These created responses match what would be stored in quiz_responses if the student does not give any answer. This usually means an empty string but RANDOM and a few other question types differ. RANDOM differs because it also stores the question id of the actual question, which is picked by its overridden implementation of ->create_response. Right after the call to ->create_response I have written a remark - 'In the future...' where I suggest that the created response should be stored in quiz_responses etc. By doing this the way it is done inside the foreach-block in the function quiz_save_attempt and having the function quiz_save_attempt update the already created records instead of inserting them I believe this bug will be fixed. I have not tested it but I do have faith in my preparations. I noticed the bug during the refactoring and also prepared for the fix as you can see. I did not fix it because the suggested fix would make the database behave slightly differently and I didn't want the refactoring to cause any database changes. Sorry about the delay - I spent the weekend traveling without internet access... From Henrik Kaipe (kaipe at users.sourceforge.net) Thursday, 16 September 2004, 07:58 PM: Fixed in version 1.178 of lib.php I hope this works but please test it anyone... — The solution contains a total of some 100 code lines tagged as WORKAROUND FOR QUESTION TYPE RANDOM spread out on three different places in the file. Therefore, I vote for a change of the response storage for random questions in accordance with my ideas under Have the input on one question stored by one row in quiz_responses in the discussion at http://moodle.org/mod/forum/discuss.php?d=10333 That database change would remove all workarounds and also simplify the code for the question type RANDOM. From Martin Dougiamas (martin at moodle.com) Sunday, 17 October 2004, 12:11 PM: Hi! Just getting back to this ...thanks for doing that workaround, Henrik! I['m keen on the proper fix for this ... More here: <a href= http://moodle.org/mod/forum/discuss.php?d=10333#67331 > http://moodle.org/mod/forum/discuss.php?d=10333#67331 </a> From Timothy Takemoto (timothy at nihonbunka.com) Wednesday, 20 October 2004, 03:11 PM: Now that there is an attempts started table (I presume) then mdl_attempts_started table then it could also be used to create a feedback page that is in the same order as the attempt. As it stands the feedback and the attempt orders do not match when random questions are being used. This seems to be confusing my students. Tim
        Hide
        Michael Blake added a comment -

        assign to a valid user

        Show
        Michael Blake added a comment - assign to a valid user

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: