Course overwriting allows users to directly overwrite internal course files on the filesystem. This power can be dangerous, as changing the course files themselves might mean that existing registrations are suddenly incompatible with the course.
For this reason, we recommend that only advanced users use the course overwriting feature. However, it is useful for simple typo fixes that do not affect the course structure or otherwise cause issues with existing registrations.
Overwrites can be done through the SCORM Cloud UI. As mentioned in that article, overwriting via the UI can be useful for testing as well, since it prompts the user to reset all existing registrations if the manifest has changed.
The notion behind course versioning is that a user uploads a new version of a course. The old version(s) of that course, along with all of the historical data that goes with them, are still kept. New registrations that are created against that course will then use the latest version. This is useful for structural changes that impact existing registrations.
In the API, to create a new version of a course, simply call
one of the course import methods with an existing course ID, and
mayCreateNewVersion set to
true. To get a list of course versions through the
API, call GetCourseVersions.
Versioning can also be done directly through the SCORM Cloud UI.
As above, new registrations against a course will use the latest course version. The behavior for existing registrations, however, is configurable.
Here are the available choices for the ‘Move Existing Registrations to Newest version’ option. Each of these is checked when the learner launches a registration.
- Never -- keep existing registrations on the old version (the default)
- If Incomplete -- if a registration is marked incomplete (or unknown)
- When Completed -- if a registration is marked complete
- When Failed -- if a registration is marked complete and failed
- When Passed -- if a registration is marked complete and passed
- Always -- always move to the latest version
When a registration moves to a later version, a new instance of that registration will be created (that is tied to the newest course version). To the learner, this will effectively reset their progress in the course. Versioning works this way because new course versions may change the structure of the course itself -- especially if multi-SCO -- so we cannot guarantee old registration state is compatible with new course versions.
Data about old instances of registrations, which are probably tied to different course versions, can be retrieved using GetRegistrationInstanceProgress. A list of instances can be retrieved using GetRegistrationInstances