Moodle
  1. Moodle
  2. MDL-22168

First Access date of SCORM SCOs is not set when launched

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.8
    • Fix Version/s: 1.9.10
    • Component/s: SCORM
    • Labels:
      None
    • Database:
      Any
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      26809

      Description

      The First Access Date should be set upon SCO launch. Currently it is not set until after the SCO is exited. This results in an inaccurate First Access data&time.

        Activity

        Hide
        valerian added a comment -

        Hi Ron and Dan,

        The access date is set for each sco with x.start.time in the beginning of a SCO session (in api.php).
        Each time a sco session is started, this value is updated.
        But i don't find any usage of this value (x.start.time) to estimate the duration spent in a SCO or anything else.
        I think we could modify locallib.php to record this value only once (when the sco is first started)
        and never updated it again for the same sco.

        This way, the first access date is set upon sco launch and results are accurate.

        Valérian

        Show
        valerian added a comment - Hi Ron and Dan, The access date is set for each sco with x.start.time in the beginning of a SCO session (in api.php). Each time a sco session is started, this value is updated. But i don't find any usage of this value (x.start.time) to estimate the duration spent in a SCO or anything else. I think we could modify locallib.php to record this value only once (when the sco is first started) and never updated it again for the same sco. This way, the first access date is set upon sco launch and results are accurate. Valérian
        Hide
        Dan Marsden added a comment -

        makes sense to me - thanks Valérian! - Ron, I've pushed this into 1.9Stable and Head - could you please test again?

        thanks!

        Show
        Dan Marsden added a comment - makes sense to me - thanks Valérian! - Ron, I've pushed this into 1.9Stable and Head - could you please test again? thanks!
        Hide
        Ron Meske added a comment -

        Hi Dan and Valerian,

        This did not fix the issue. I was able to conduct some testing and found that the record and thus the date is not created until the SCORM LMSCommit is executed. This makes sense since the API is not suppose to send any data back until the LMSCommit is executed. However, this means First Access is not set until that time either.

        Can the First Access be set upon SCO launch instead?

        Ron

        Show
        Ron Meske added a comment - Hi Dan and Valerian, This did not fix the issue. I was able to conduct some testing and found that the record and thus the date is not created until the SCORM LMSCommit is executed. This makes sense since the API is not suppose to send any data back until the LMSCommit is executed. However, this means First Access is not set until that time either. Can the First Access be set upon SCO launch instead? Ron
        Hide
        Ron Meske added a comment -

        A slight edit to the above. The First Access Date and Time is updated with each LMSCommit until LMSFinish is executed. Then it will remain locked. So what happens is until the SCO sends the LMSFinish and exits the First Access Date is updated.

        Show
        Ron Meske added a comment - A slight edit to the above. The First Access Date and Time is updated with each LMSCommit until LMSFinish is executed. Then it will remain locked. So what happens is until the SCO sends the LMSFinish and exits the First Access Date is updated.
        Hide
        valerian added a comment -

        Hi Ron,

        Which Moodle version are you working on ?
        I'm on 1.9.8 and x.start.time is set in mod/scorm/api.php (line 85) when this file is loaded by player.php.
        The x.start.time value is set as soon as the api is loaded, no matter if LMSCommit, LMSFinish or LMSInitialize is called. This recording of x.start.time is independant from the api.

        I've just make some tests, stopping my sco session before any call to the api. The only thing recorded in db is the x.start.time value in the begining of the session and in the report i can see accurate first access and last access date (in this case they are the same).

        Show
        valerian added a comment - Hi Ron, Which Moodle version are you working on ? I'm on 1.9.8 and x.start.time is set in mod/scorm/api.php (line 85) when this file is loaded by player.php. The x.start.time value is set as soon as the api is loaded, no matter if LMSCommit, LMSFinish or LMSInitialize is called. This recording of x.start.time is independant from the api. I've just make some tests, stopping my sco session before any call to the api. The only thing recorded in db is the x.start.time value in the begining of the session and in the report i can see accurate first access and last access date (in this case they are the same).
        Hide
        Ron Meske added a comment -

        Hi Valerian,

        I am using the latest 1.9Stable branch from CVS.

        To conduct the test I opened two browser windows, one signed in as an Admin and the other as a student. This allowed me to check the SCORM report while executing a SCO. The steps to re-create this are:

        1. Launch SCO
        2. Execute LMSInitialize
        3. Check SCORM report - No record of attempt
        4. Set core.lesson_status to incomplete
        5. Check SCORM report - No record of attempt
        6. set core.exit to suspend
        7. Check SCORM report - No record of attempt
        8. call LMSCommit
        9. Check SCORM report - Record of attempt reported with First access time/date stamp equal to time/date of LMSCommit
        10. Set session_time
        11. call LMSCommit
        12. Check SCORM report - First access time/date stamp updated to time/date of second LMSCommit
        13. call LMSFinish
        14. Exit SCO
        15. Check SCORM report - First access time/date stamp updated to time/date of LMSFinish

        16. Relaunch SCO
        17. call LMSInitialize
        18. Check SCORM report - Record not changed
        19. Set core.lesson_status to complete
        20. Check SCORM report - Record not changed
        21. set core.exit to blank
        22. Check SCORM report - Record not changed
        23. call LMSCommit
        24. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSCommit
        25. Set session_time
        26. call LMSCommit
        27. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSCommit
        28. call LMSFinish
        29. Exit SCO
        30. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSFinish

        Show
        Ron Meske added a comment - Hi Valerian, I am using the latest 1.9Stable branch from CVS. To conduct the test I opened two browser windows, one signed in as an Admin and the other as a student. This allowed me to check the SCORM report while executing a SCO. The steps to re-create this are: 1. Launch SCO 2. Execute LMSInitialize 3. Check SCORM report - No record of attempt 4. Set core.lesson_status to incomplete 5. Check SCORM report - No record of attempt 6. set core.exit to suspend 7. Check SCORM report - No record of attempt 8. call LMSCommit 9. Check SCORM report - Record of attempt reported with First access time/date stamp equal to time/date of LMSCommit 10. Set session_time 11. call LMSCommit 12. Check SCORM report - First access time/date stamp updated to time/date of second LMSCommit 13. call LMSFinish 14. Exit SCO 15. Check SCORM report - First access time/date stamp updated to time/date of LMSFinish 16. Relaunch SCO 17. call LMSInitialize 18. Check SCORM report - Record not changed 19. Set core.lesson_status to complete 20. Check SCORM report - Record not changed 21. set core.exit to blank 22. Check SCORM report - Record not changed 23. call LMSCommit 24. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSCommit 25. Set session_time 26. call LMSCommit 27. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSCommit 28. call LMSFinish 29. Exit SCO 30. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSFinish
        Hide
        valerian added a comment -

        Hi Ron,
        I'll check this as soon as i can.
        Valérain

        Show
        valerian added a comment - Hi Ron, I'll check this as soon as i can. Valérain
        Hide
        valerian added a comment -

        Hi,

        In last revision of the file loaddatamodel.php (for Moodle 2.0), the call to scorm_insert_track has been removed.
        With Dan latest backport to 1.9 Stable this call has been removed from api.php (for Moodle 1.9).
        That's why the x.start.time value is not recorded on sco launch. In fact, it's never recorded now.

        This has been removed in Revision 1.9 of loaddatamodel.php by Piers. Maybe we could reintegrate this ?

        Show
        valerian added a comment - Hi, In last revision of the file loaddatamodel.php (for Moodle 2.0), the call to scorm_insert_track has been removed. With Dan latest backport to 1.9 Stable this call has been removed from api.php (for Moodle 1.9). That's why the x.start.time value is not recorded on sco launch. In fact, it's never recorded now. This has been removed in Revision 1.9 of loaddatamodel.php by Piers. Maybe we could reintegrate this ?
        Hide
        Ron Meske added a comment -

        Seems like the status of resolved should be reversed as this is not fixed.

        Show
        Ron Meske added a comment - Seems like the status of resolved should be reversed as this is not fixed.
        Hide
        Dan Marsden added a comment -

        weird - not sure what happened there - will fix up after "testing tuesday" is finished.

        Show
        Dan Marsden added a comment - weird - not sure what happened there - will fix up after "testing tuesday" is finished.
        Hide
        Dan Marsden added a comment -

        fix pushed back into 1.9Stable and Head - sorry about that Ron! - can you please re-test and confirm that we've got it right now?

        thanks!

        Dan

        Show
        Dan Marsden added a comment - fix pushed back into 1.9Stable and Head - sorry about that Ron! - can you please re-test and confirm that we've got it right now? thanks! Dan

          People

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

            Dates

            • Created:
              Updated:
              Resolved: