NEW FEATURES

Course Summary Report

Under the Course Report section of CC, there is a new “Build Report” button that lets you select one or more courses for a high-level summary report. This report provides an account-by-account breakdown of usage numbers, completion rates, average scores, number of learners in each score quartile, and average durations. It can be shared as a link or exported as a CSV file.

Learner Report Column Presets

Users have always been able to add and remove columns from the Learner Report table. However, those choices weren’t saved, so you’d have to redo it all every time you came back to make another report. Now you can save your column choices with a name, and load them again later without having to scroll through a long list of interactions.

Multi-Course Learner Report

The Learner Report used to show results for all learners in a selected account that have taken a selected course. Now you can select multiple courses from a single account, and see data about all the learners who have taken at least one of those courses.

Report Performance

As customer datasets have grown over the years, we've noticed that some of our reports are taking longer to generate than they should. Along with all of the reporting improvements mentioned above, we also revisited how we generate our existing reports, and we improved their performance. Many of the reports should now run faster than they did on previous versions of CC.

Audio Courses

Now you can import MP3 audio files, and distribute them to LMSs just as you would with any other supported content type. Tracking results for audio courses works like video, with completion and duration reported to the launching LMS and xAPI statements for user interactions with the audio player that can be forwarded to your LRS.

API Credential Improvements

We've made a few improvements to the credentials used to access our automation API. Firstly, we changed how API credential creation works. In previous versions, all API credentials had access to everything in the application. Now, we've added the ability to create read-only credentials that can be scoped to only access specific accounts. When creating a new set of API credentials, you can choose if the credentials should be admin credentials (with access to everything) or if they should be limited in scope. All API credentials created before CC 3.1 will be treated as admin credentials, but that can be changed at any time after upgrading.

Additionally, we've improved how we store the credentials in our database. Previously, we were storing the credential key and secret in plaintext so that users can easily retrieve their information from the application. However, we've decided to better adhere to best practices and start only storing the hash of the credential key in the database. This protects your API credentials in the event that your database is ever compromised.

Potentially Breaking Changes:

The improvements that we've made with this release required us to make a few potentially backward-incompatible changes:

• API credential secret values are now hashed in the database. Previously, secret values were stored in the DB and displayed through the UI in plain text. We now hash the credential secrets and only provide the credential's secret immediately after the credential has been created. Upon deploying a 3.1 CC instance, all existing secret values will be hashed. So, before deploying, secret values of any existing credentials should be saved and stored. After you have been upgraded to 3.1, it will become impossible to retrieve the credential's secret from Content Controller.
• The API results for course configurations have been normalized. Rather than returning a mixture of true/false and YES/NO, the settings endpoints will now only return true/false. We don't expect this will break anyone's integration with our automation API, but we wanted to mention it just in case.
• Due to improvements made to the learner report, links to share a learner report that was created before upgrading to 3.1 will not work after the upgrade.

Note to self-hosted customers:

Content Controller is built around its sister product, Rustici Engine. When upgrading between major versions (e.g. 2.2.xxx -> 3.0.xx or 3.0.xx -> 3.1.xx), we need to also upgrade Engine's database schema. To do this, just add the argument -e engine_upgrade=true to the command for running your playbooks. This flag tells Ansible that this particular deployment requires the Engine upgrade. You won't be required to use this flag when moving between maintenance releases (e.g. 3.1.309 -> 3.1.314) unless specified in the release.