XMLWordPrintable

    • Icon: Sub-task Sub-task
    • Resolution: Fixed
    • Icon: Minor Minor
    • 2.8
    • 2.8
    • SCORM add-on
    • Hide

      There are A LOT of synchronization cases to test. Here are some of them:

      1. A SCORM only has online attempts. Sync button shouldn't be shown.
      2. A SCORM only has offline attempts. They should all be sent.
      3. A SCORM has completed online attempts and 1+ offline attempts consecutive to the online ones (the app had the online attempts synced and then it created the offline attempts). Offline attempts should be sent.
      4. A SCORM has completed online attempts and 1+ offline attempts NOT consecutive to the online ones (the app created the offline attempts and at the same time the online attempts were made in browser). The offline attempts numbers should be changed to place them AFTER the online ones and they should be sent without surpassing max attempts.
      5. A SCORM has an incomplete online attempt and 1+ offline attempts NOT related to the online one (the app created the offline attempts and at the same time the online attempt was made in browser). The offline attempts numbers should be changed to place them AFTER the online one but they can't be sent because the last online attempt is incomplete.
      6. A SCORM has an online attempt that's continued in offline. The offline data should be sent as if the user had continued the attempt in online.
      7. A SCORM has an online attempt that's continue in offline, but the online attempt is modified in Moodle before the app syncs. The offline data should be created as a new attempt. If the app had more offline attempts, they'll be moved to keep the order of attempts.
      8. After a synchronization, some offline attempts couldn't be sent because last online attempt was incomplete. The user should be able to continue the last online attempt. There are some subcases in here:
        • The user continues the online attempt and finishes it without losing connection. The offline attempts should now be sent after the online one.
        • The user continues the online attempt but loses connection. He finishes the attempt and it hasn't been modified in browser. The offline data is synchronized to the online attempt and new offline attemtps are sent after the online one.
        • The user continues the online attempt but loses connection. He finishes the attempt but it has been modified in browser. If last offline attempt is completed, the offline data will be created as a new attempt at the end of the list. If last offline attempt is incomplete, offline data will be deleted.

      Cases where synchronization can be triggered:

      1. When the user access a SCORM entry page if it hasn't been synced in the last 5 minutes.
      2. Pressing synchronization button in a SCORM entry page.
      3. Leaving a SCORM player.
      4. Pull to refresh in SCORM entry page.
      5. When going online or login into a site in online, all SCORMs with data to sync that haven't been synced in the last 5 minutes will be synced (except if it's being played right now).
      Show
      There are A LOT of synchronization cases to test. Here are some of them: A SCORM only has online attempts. Sync button shouldn't be shown. A SCORM only has offline attempts. They should all be sent. A SCORM has completed online attempts and 1+ offline attempts consecutive to the online ones (the app had the online attempts synced and then it created the offline attempts). Offline attempts should be sent. A SCORM has completed online attempts and 1+ offline attempts NOT consecutive to the online ones (the app created the offline attempts and at the same time the online attempts were made in browser). The offline attempts numbers should be changed to place them AFTER the online ones and they should be sent without surpassing max attempts. A SCORM has an incomplete online attempt and 1+ offline attempts NOT related to the online one (the app created the offline attempts and at the same time the online attempt was made in browser). The offline attempts numbers should be changed to place them AFTER the online one but they can't be sent because the last online attempt is incomplete. A SCORM has an online attempt that's continued in offline. The offline data should be sent as if the user had continued the attempt in online. A SCORM has an online attempt that's continue in offline, but the online attempt is modified in Moodle before the app syncs. The offline data should be created as a new attempt. If the app had more offline attempts, they'll be moved to keep the order of attempts. After a synchronization, some offline attempts couldn't be sent because last online attempt was incomplete. The user should be able to continue the last online attempt. There are some subcases in here: The user continues the online attempt and finishes it without losing connection. The offline attempts should now be sent after the online one. The user continues the online attempt but loses connection. He finishes the attempt and it hasn't been modified in browser. The offline data is synchronized to the online attempt and new offline attemtps are sent after the online one. The user continues the online attempt but loses connection. He finishes the attempt but it has been modified in browser. If last offline attempt is completed, the offline data will be created as a new attempt at the end of the list. If last offline attempt is incomplete, offline data will be deleted. Cases where synchronization can be triggered: When the user access a SCORM entry page if it hasn't been synced in the last 5 minutes. Pressing synchronization button in a SCORM entry page. Leaving a SCORM player. Pull to refresh in SCORM entry page. When going online or login into a site in online, all SCORMs with data to sync that haven't been synced in the last 5 minutes will be synced (except if it's being played right now).
    • MOODLE_28_STABLE
    • MOODLE_28_STABLE

      We need a clever process able to synchronize offline attempts data with Moodle. It should handle all the cases and display a list of not synchronized status so the user can check it out.

            dpalou Dani Palou
            jleyva Juan Leyva
            Juan Leyva Juan Leyva
            Juan Leyva Juan Leyva
            Juan Leyva Juan Leyva
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:

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