Note: If you are upgrading from a version of Engine before 2019.1, please see this Breaking Changes for 2019.1 article. Everything in that article will apply as well.
Here's a list of things that have been changed/removed in 20.1:
- Switch default of
UsePlayerForTinCanLaunches(to "true") so that Tin Can launches go through the player by default.
In previous releases Tin Can packages were launched directly to the course content URL without the normal player delivery context. This setting was added in 2017.1.26.864 as an improvement to Dispatch with the default value being "false" to maintain backwards compatibility. Switching the default in this release is intended to make the launch + delivery mechanism consistent across all learning standards. For courses that might rely on being delivered directly the value of the setting should be set to `false`. - Drop IE 8 support
As Engine attempts to keep up with modern web browser implementations and security requirements it has become increasingly difficult to support very old browsers. In this version the jQuery dependency was upgraded to fix a CVE that was reported in the previously used version. Additionally the process for minifying the various client side JavaScript will no longer take precautions to support IE 8.
The development team decided this was an appropriate time to move to the latest main release of that library and drop support for IE 8. It is very likely that additional versions of IE such as 9 and 10 will be dropped from the next major release as Engine moves to only support Microsoft Edge in the future. All IE support should be considered deprecated with likely removal in the next major release. - Use timestamp from xAPI statement for registration update dates
In previous versions, when an xAPI statement was received for a launched registration and we rolled up information from it to the registration, we would use the time from when that rollup happened as the basis for completedDate and lastAccessDate. In most cases this was basically identical to the timestamp the course put on the statement.
However, in some cases, especially with our new on-demand registrations, we may have statements that are processed at a time later from when the course set the timestamp. That could make the completedDate incorrect in situations where minutes or hours difference may matter. We now will use the timestamp from the statement as the basis for these dates on the registration, as it more accurately reflects when the action happened for the user.
If you don't want this change in behavior, there is a new setting,UseStatementTimestampInRegistrationUpdates, which can be used to restore the previous behavior. - .NET Engine is now a "Web Application" rather than "Web Project"
As with the change in browser support, the development team is attempting to modernize the Engine product and codebase to prepare it to support newer (or future) technologies (such as .NET Core and .NET 5). This change was made to facilitate that slow transition. Expect additional changes of this nature, as we deprecate support for older versions of the .NET framework. -
Require playerConfigurationUrl.json file for Remote Deliver deployments
For those using our RemoteDeliverPageUrl setting in order to configure Engine to launch the player page from a location other than its default in the Engine web application, there is a new requirement. In order to close a security vulnerability in how we pass the configuration url to the player, we now create the path to that relative to the player page itself.
This works fine for all normal deployments, but for those using RemoteDeliverPageUrl, where the player page is on a completely different domain/server from Engine, it will not work.
To work around this, there is now a file, playerConfigurationUrl.json, in the /player folder that is deployed on the remote server. This will need to be modified to include the appropriate playerConfigurationUrl property value that points back to the page in Engine (eg, "https://mydomain.com/RusticiEngine/PlayerConfiguration.jsp").
At runtime, for these remote deployments, Engine will retrieve this JSON file to determine what url to use to retrieve the player configuration data.
Here is a list of things changed only for customers using Engine Dispatch:
POST /destinations, PUT /destinations- POST can only create and PUT can only edit
In previous versions of Engine, the v2 API endpoints for manipulating Dispatch destinations were not well aligned with the rest of the API with respect to creating and editing of those records. This changes those API resources to be consistent with how those methods work in other resources. If you were previously using the PUT verb to create destinations, you will need to switch to using POST.- Learner IDs for dispatch registrations will now be prepended with the destinationId in order to ensure uniqueness. Previously, Engine was using only what was sent by the LMS launching the dispatch package.
One side effect of this would be that the same learner could be counted as two different unique users in your user counts for licensing purposes, if they launch a dispatched course for the first time after the upgrade to Engine 20.1 during your license year.
There is a new setting,DispatchPrependDestinationIdForLearner, which can be used to turn off this new behavior and revert to how it worked previously. However, there is the possibility of learner id collisions. If you think disabling this behavior is necessary, you might consider re-enabling it once you reach the end of your license year.
If you are using the Offline extension to Engine:
- We have tried to simplify and improve the way that mobile applications interact with Engine for the Offline Extension. This release has major changes to the workflow on the Engine side, and for the mobile application. Upgrading to this release will require changes your mobile application and downloading the course packages to the device again.