Hello everyone,
The following versions of Totara Learn have now been released:
- Release Evergreen
- Release 12.11
- Release 11.20
- Release 10.26
- Release 9.37
- Release 2.6.71
- Release 2.5.77
- Release 2.4.73
- Release 2.2.75
These releases contain many fixes and improvements.
Notably they include fixes for upcoming changes in Chrome version 80.
We strongly recommend all sites with end users running the latest version of Chrome upgrade to these releases.
Please read the following changelogs for more information.
Kind regards
Sam Hemelryk
Release Evergreen (25th October 2019):
Key: + Evergreen only
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* Cookies default to SameSite=Lax
* Reject insecure SameSite=None cookies
TL-22408 Fixed two issues that could cause the tag name upgrade step to fail
As part of the fix for TL-21055 (introduced in 11.17, and 12.8), we
created an upgrade step to revert HTML-encoded tag names to their original,
non-encoded canonical state.
The upgrade step failed to take two conditions into account: multiple tag
instances on the same item that resolve to the same canonical tag; and
module tags that resolve to the same canonical tag as a course. In these
cases, the upgrade simply failed with a database exception.
The tags upgrade step has been rewritten to work properly in all
situations.
TL-22560 Improved the handling of conditional access restrictions that reference deleted items
Fixed a bug that prevented editing the access restrictions when a deleted
audience, position, or organisation was used as part of a restriction set
in them
We also made changes to stop removing course activity access restrictions
that refer to those deleted items.
In previous versions, whenever an audience, position, or organisation was
deleted, all access restrictions referring to the deleted item were
removed.
This could result in learners being able to access sections and activities
that they were unable to access before.
With this release, access restrictions are kept in place if the item(s)
they refer to are deleted. Such restrictions are updated to refer to a
'missing audience', 'missing position', or 'missing organisation', and will
prevent access to everybody until either removed or associated with a
different item.
Please note:
* If a 'missing' restriction is part of an OR condition, it will simply not
match rather than preventing access.
* If a 'must not' restriction is 'missing,' then learners who formerly met
the restriction condition will not be restricted any more.
* There is no way to recover access restrictions that were previously
deleted because they referred to deleted items.
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
https://www.chromestatus.com/feature/4664843055398912
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Performance improvements:
TL-21839 Improved the performance of the 'Progress' column within program and certification report sources
TL-21853 + Improved the performance of the course and category management interface
The contents of each category's 'Actions' cog menu on the 'Course and
category management' page is now rendered upon request. This provides a
noticeable performance improvement over rendering them all in advance.
TL-22262 Improved the performance of the calendar on sites with a large number of seminars per month
Calendar events are now filtered for visibility as they are loaded from the
database, rather than being checked one-by-one after being loaded.
TL-22323 Improved overall in-browser page performance when a large number of popovers are present
TL-22421 Added a new database index on role_capabilities (capability, roleid, permission)
This index has a profound impact on query performance when resolving
capability checks directly against the database.
TL-22457 Added a new database index on cache_flags (flagtype, expiry, timemodified)
TL-22461 Added a new database index on course (category,sortorder)
TL-22471 Initialising HR Import settings for administrators no longer queries the database
TL-22473 Optimised the course category management page to preload courses and course counts
TL-22474 Optimised the navigation structure performance using totara_course_is_viewable
Site navigation was originally using totara_visibility_where when resolving
course visibility.
It has now been converted to use totara_course_is_viewable, given that the
number of courses loaded into the navigation is limited, and in displaying
the course within the navigation we must load all of the information to
resolve its visibility.
TL-22475 Optimised enrol_get_my_courses to use totara_course_is_viewable
The enrol_get_my_courses method was originally using
totara_visibility_where when resolving course visibility. It has now been
converted to use totara_course_is_viewable, given the information available
within the function and that in most circumstances enrolled users can see
the courses they are enrolled it.
TL-22478 Added a new database index on block_instances (blockname)
There are several queries within the platform, some that are executed on
most pages, that look up block instances by name.
While the queries are simple the table itself can grow significantly and
having an index on the blockname column aids database performance.
TL-22611 Optimised the enrol_get_all_users_courses function to use totara_course_is_viewable
Improvements:
TL-7967 + Changed the certification workflow to only reset primary certification path on expiry
Previously, when a recertification window opened, courses on both primary
certification and recertification paths were reset. Now only the
recertification path courses will be reset when the recertification window
opens. Primary certification path courses will now be reset only on expiry,
and only if they are not also on the recertification path. This ensures
that courses are only reset when they need to be recompleted, and that
progress towards recertification, if applicable, will contribute to primary
certification in the event of a user's certification expiring.
TL-20397 + Redesigned the user reports page
User report page was redesigned replacing the list of reports with a
grid-like user interface showing report thumbnails that reflect the nature
of the report:
* Table reports
* Graphical reports (with different thumbnails for each chart type)
Added a new button to create new reports to the page that will be shown to
users with appropriate permissions.
TL-21595 + Added backend support for report templates in report builder
TL-21686 + Added inline editing of report titles when viewing a report
TL-22051 Implemented a means to bulk delete unstarted course completions belonging to users who are no longer enrolled
When users are mistakenly enrolled, and then immediately unenrolled in a
course, a course completion record is left behind. This record is marked as
un-started, and can be manually deleted using the course completion
editor.
Manually deleting many thousands of records, as might need to happen when a
large audience is accidentally enrolled and then unenrolled from a course,
is prohibitively time-consuming. A new CLI script has been added at
'admin/cli/delete_unused_course_completions.php' to accomplish these
deletions in bulk.
Using the script will trigger an 'Admin CLI script execution, records
deleted' event that includes the parameters it was called with.
TL-22132 + Added 'Labels' and 'Summary' fields to Report Builder sources
Report Builder source classes now have 'sourcelabel' and 'sourcesummary'
properties which will be used in the new report creation workflow.
TL-22260 Added the control of Report Builder export options at a report level
TL-22389 Migrated all documentation links to point to help.totaralearning.com
All links to external documentation within the product take the user to the
appropriate page in our public product documentation available at
help.totaralearning.com
TL-22854 Fixed compatibility with PostgreSQL 12.0
Bug fixes:
TL-20100 Removed a redundant and inaccurate help popup for appraisal descriptions
TL-21346 Fixed seminar restoration when the original seminar had been deleted but still existed within the recycle bin
TL-21828 Fixed Behat scenarios attempting to click on select input options after recent changes in Chrome
Recent changes in Chrome have led to sporadic issues through our Behat
features relating back to the definitions that attempt to click on options
within a select input. All affected feature files have been converted to a
method that works in all versions of Chrome.
TL-21992 + Fixed incorrect graph layouts when using the progress chart type
TL-22001 + Fixed minor visual bugs in ChartJS pie and doughnut charts
Several small visual improvements have been made to the pie and doughnut
chart types within ChartJS:
* Chart colours have been adjusted to ensure similar hues no longer appear
next to each other in a chart.
* Thin white borders have been added between slices.
* Increased the inner edge diameter for doughnut charts, reducing their
thickness.
TL-22207 Block permissions for authenticated users and guests are now restored corectly when restoring a course
In addition to the above noted fix the screen displaying information on
roles that cannot be mapped during restore now correctly displays built-in
role names and overridable roles.
TL-22224 Fixed the grade functions of the seminar component to be compatible with other activity components
TL-22241 + Fixed the description of date-based dynamic audience rules to match the back-end logic
TL-22257 Added a missing capability check to stop an error message while adding an enrolled audience to a course
TL-22348 Changed the default timesort for the Grid catalogue
Previously the time-based sorting method for the new grid-style catalogue
was based on the 'timemodified' value of the learning items being
displayed. This has been changed to use the 'timecreated' value instead,
giving a more consistent ordering of the learning items.
Note: Though the back-end code has been updated, this change will not be
visible on the catalogue until the refresh_catalog_data scheduled task is
run. If you want to see this change immediately please manually run the
task after upgrading, otherwise this change will only be updated on the
next scheduled run.
TL-22349 Fixed custom navigation parent elements being un-deletable after upgrade
TL-22394 Fixed the overflow of long category names within the Grid catalogue
Previously if long category names could extend under the tiles when using
the Grid catalogue. The maximum width of the category name is now managed,
and an ellipsis presented when the category name would exceed the available
space.
This will require CSS to be regenerated for themes that use LESS
inheritance.
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
TL-22401 Removed unnecessary use of set context on report builder filters page
TL-22418 + Fixed schema introspection for GraphQL
TL-22419 Corrected link colours within a label course activity
This will require CSS to be regenerated for themes that use LESS
inheritance.
TL-22435 Fixed context used for capability checks during goal userdata exports
Previously the goal exports were checking if a user could see their own
goals in the system context, however the capability is meant to be used in
the user context. This has been rectified where possible.
TL-22453 Featured links blocks no longer uses the text colour specified in Basis theme settings
The text colour specified in Basis theme settings is designed to work on
light backgrounds, not the dark background that the featured links block
uses.
This will require CSS to be regenerated for themes that use LESS
inheritance.
TL-22511 Deleting course completions either via the interface or via CLI now correctly purges completion caches
TL-22517 Fixed an error in first login tasks when a user has future assignments for multiple programs or certifications
If a user had multiple future assignments (due to setting a program due
date based on first login for a user who hadn't yet logged in), when the
first_login_assignments task ran, an error would be generated and users
wouldn't be assigned to the program / certification correctly.
TL-22518 Fixed email-based self registration with position, organisation, and manager while logged in as a guest
TL-22559 Seminar notification sender no longer reuses the sending user object
The reuse of the sending user object when sending notifications from within
the seminar occasionally led to an issue where notifications would appear
to come from random users. This has now been fixed by ensuring a fresh
sending user object is used for each notification.
TL-22567 Made sure the 'Front page settings' page can be bookmarked in the administration menu
TL-22576 All areas displaying a program or certification fullname are now formatted consistently
Prior to this change there were a handful of areas not correctly formatting
program and certification full names before displaying them. These have all
been tidied up and program and certification fullname is now formatted
correctly and consistently.
TL-22582 Fixed a race condition in the Grid catalogue page that inadvertently reset filter settings
A race condition was identified in the auto-initialise AMD module, whereby
components could have been initialised out of order. In situations where
the anticipated order of execution was being relied upon this could
manifest visible errors such as catalogue filters from a shared URL being
incorrectly excluded.
This race condition has now been fixed and calls to require AMD modules are
now processed in advance of auto-initialisation.
TL-22610 Fixed error in HR Import when importing organisation or position custom fields when typeidnumber is mapped
When importing organisation or position custom fields using HR Import, if a
field mapping was used in the typeidnumber field an error would be thrown
causing the import to fail. This has been fixed.
TL-22622 Fixed an incorrect count of visible programs which led to missing pagination controls in the interface
This is a regression introduced by TL-22060 released in 12.10 last month.
The total count variable within prog_get_programs_page() was being
incorrectly populated after that change. It is now correctly populated.
TL-22632 Fixed the report builder default fetch method setting as its value was not being respected
TL-22658 Fixed the display of programs and certifications when folders are added to their image field
Folders are now ignored when added to the image field for programs and
certifications.
The ability to add folders will be removed in a future version by TL-22659.
API changes:
TL-22248 Checks to confirm a user can log in as another user are now performed by the user access controller
'Login as' permission checks have been consolidated into a new method on
the user access controller, \core_user\access_controller::can_loginas()
Existing checks within the product have all been converted to use this new
method, ensuring that the control checks are applied consistently.
TL-22392 Added course creation post definition and validation hooks
This change introduced two new hooks:
* \core_course\hook\edit_form_definition_after_data
* \core_course\hook\edit_form_validation
TL-22472 Removed incorrect use of $DB->sql_like() for non-unicode fields
SQL code executing LIKE statements on the context path in the database was
in some situations using sql_like, which led to collation management being
introduced. This was leading to an unnecessary overhead as path is a
calculated field for which we always know the character range used.
TL-22477 Active string filters per context are now cached using MUC
Previously a static variable $FILTERLIB_PRIVATE was used to cache active
filters by context during the lifetime of a request. This has been
converted to an MUC request cache, allowing for better management and
handling both in product and in our testing environments.
Contributions:
* Davo Smith at Synergy Learning - TL-22518
* Peter Spicer at Catalyst EU - TL-22392
Release 12.11 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* Cookies default to SameSite=Lax
* Reject insecure SameSite=None cookies
TL-22408 Fixed two issues that could cause the tag name upgrade step to fail
As part of the fix for TL-21055 (introduced in 11.17, and 12.8), we
created an upgrade step to revert HTML-encoded tag names to their original,
non-encoded canonical state.
The upgrade step failed to take two conditions into account: multiple tag
instances on the same item that resolve to the same canonical tag; and
module tags that resolve to the same canonical tag as a course. In these
cases, the upgrade simply failed with a database exception.
The tags upgrade step has been rewritten to work properly in all
situations.
TL-22560 Improved the handling of conditional access restrictions that reference deleted items
Fixed a bug that prevented editing the access restrictions when a deleted
audience, position, or organisation was used as part of a restriction set
in them
We also made changes to stop removing course activity access restrictions
that refer to those deleted items.
In previous versions, whenever an audience, position, or organisation was
deleted, all access restrictions referring to the deleted item were
removed.
This could result in learners being able to access sections and activities
that they were unable to access before.
With this release, access restrictions are kept in place if the item(s)
they refer to are deleted. Such restrictions are updated to refer to a
'missing audience', 'missing position', or 'missing organisation', and will
prevent access to everybody until either removed or associated with a
different item.
Please note:
* If a 'missing' restriction is part of an OR condition, it will simply not
match rather than preventing access.
* If a 'must not' restriction is 'missing,' then learners who formerly met
the restriction condition will not be restricted any more.
* There is no way to recover access restrictions that were previously
deleted because they referred to deleted items.
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
https://www.chromestatus.com/feature/4664843055398912
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Performance improvements:
TL-21839 Improved the performance of the 'Progress' column within program and certification report sources
TL-22262 Improved the performance of the calendar on sites with a large number of seminars per month
Calendar events are now filtered for visibility as they are loaded from the
database, rather than being checked one-by-one after being loaded.
TL-22323 Improved overall in-browser page performance when a large number of popovers are present
TL-22421 Added a new database index on role_capabilities (capability, roleid, permission)
This index has a profound impact on query performance when resolving
capability checks directly against the database.
TL-22457 Added a new database index on cache_flags (flagtype, expiry, timemodified)
TL-22461 Added a new database index on course (category,sortorder)
TL-22471 Initialising HR Import settings for administrators no longer queries the database
TL-22473 Optimised the course category management page to preload courses and course counts
TL-22474 Optimised the navigation structure performance using totara_course_is_viewable
Site navigation was originally using totara_visibility_where when resolving
course visibility.
It has now been converted to use totara_course_is_viewable, given that the
number of courses loaded into the navigation is limited, and in displaying
the course within the navigation we must load all of the information to
resolve its visibility.
TL-22475 Optimised enrol_get_my_courses to use totara_course_is_viewable
The enrol_get_my_courses method was originally using
totara_visibility_where when resolving course visibility. It has now been
converted to use totara_course_is_viewable, given the information available
within the function and that in most circumstances enrolled users can see
the courses they are enrolled it.
TL-22478 Added a new database index on block_instances (blockname)
There are several queries within the platform, some that are executed on
most pages, that look up block instances by name.
While the queries are simple the table itself can grow significantly and
having an index on the blockname column aids database performance.
TL-22611 Optimised the enrol_get_all_users_courses function to use totara_course_is_viewable
Improvements:
TL-22051 Implemented a means to bulk delete unstarted course completions belonging to users who are no longer enrolled
When users are mistakenly enrolled, and then immediately unenrolled in a
course, a course completion record is left behind. This record is marked as
un-started, and can be manually deleted using the course completion
editor.
Manually deleting many thousands of records, as might need to happen when a
large audience is accidentally enrolled and then unenrolled from a course,
is prohibitively time-consuming. A new CLI script has been added at
'admin/cli/delete_unused_course_completions.php' to accomplish these
deletions in bulk.
Using the script will trigger an 'Admin CLI script execution, records
deleted' event that includes the parameters it was called with.
TL-22260 Added the control of Report Builder export options at a report level
TL-22389 Migrated all documentation links to point to help.totaralearning.com
All links to external documentation within the product take the user to the
appropriate page in our public product documentation available at
help.totaralearning.com
TL-22854 Fixed compatibility with PostgreSQL 12.0
Bug fixes:
TL-20100 Removed a redundant and inaccurate help popup for appraisal descriptions
TL-21346 Fixed seminar restoration when the original seminar had been deleted but still existed within the recycle bin
TL-21828 Fixed Behat scenarios attempting to click on select input options after recent changes in Chrome
Recent changes in Chrome have led to sporadic issues through our Behat
features relating back to the definitions that attempt to click on options
within a select input. All affected feature files have been converted to a
method that works in all versions of Chrome.
TL-22207 Block permissions for authenticated users and guests are now restored corectly when restoring a course
In addition to the above noted fix the screen displaying information on
roles that cannot be mapped during restore now correctly displays built-in
role names and overridable roles.
TL-22224 Fixed the grade functions of the seminar component to be compatible with other activity components
TL-22243 Removed double-escaping of ampersands in the featured links block
TL-22257 Added a missing capability check to stop an error message while adding an enrolled audience to a course
TL-22348 Changed the default timesort for the Grid catalogue
Previously the time-based sorting method for the new grid-style catalogue
was based on the 'timemodified' value of the learning items being
displayed. This has been changed to use the 'timecreated' value instead,
giving a more consistent ordering of the learning items.
Note: Though the back-end code has been updated, this change will not be
visible on the catalogue until the refresh_catalog_data scheduled task is
run. If you want to see this change immediately please manually run the
task after upgrading, otherwise this change will only be updated on the
next scheduled run.
TL-22349 Fixed custom navigation parent elements being un-deletable after upgrade
TL-22394 Fixed the overflow of long category names within the Grid catalogue
Previously if long category names could extend under the tiles when using
the Grid catalogue. The maximum width of the category name is now managed,
and an ellipsis presented when the category name would exceed the available
space.
This will require CSS to be regenerated for themes that use LESS
inheritance.
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
TL-22401 Removed unnecessary use of set context on report builder filters page
TL-22419 Corrected link colours within a label course activity
This will require CSS to be regenerated for themes that use LESS
inheritance.
TL-22435 Fixed context used for capability checks during goal userdata exports
Previously the goal exports were checking if a user could see their own
goals in the system context, however the capability is meant to be used in
the user context. This has been rectified where possible.
TL-22453 Featured links blocks no longer uses the text colour specified in Basis theme settings
The text colour specified in Basis theme settings is designed to work on
light backgrounds, not the dark background that the featured links block
uses.
This will require CSS to be regenerated for themes that use LESS
inheritance.
TL-22511 Deleting course completions either via the interface or via CLI now correctly purges completion caches
TL-22517 Fixed an error in first login tasks when a user has future assignments for multiple programs or certifications
If a user had multiple future assignments (due to setting a program due
date based on first login for a user who hadn't yet logged in), when the
first_login_assignments task ran, an error would be generated and users
wouldn't be assigned to the program / certification correctly.
TL-22518 Fixed email-based self registration with position, organisation, and manager while logged in as a guest
TL-22559 Seminar notification sender no longer reuses the sending user object
The reuse of the sending user object when sending notifications from within
the seminar occasionally led to an issue where notifications would appear
to come from random users. This has now been fixed by ensuring a fresh
sending user object is used for each notification.
TL-22567 Made sure the 'Front page settings' page can be bookmarked in the administration menu
TL-22576 All areas displaying a program or certification fullname are now formatted consistently
Prior to this change there were a handful of areas not correctly formatting
program and certification full names before displaying them. These have all
been tidied up and program and certification fullname is now formatted
correctly and consistently.
TL-22582 Fixed a race condition in the Grid catalogue page that inadvertently reset filter settings
A race condition was identified in the auto-initialise AMD module, whereby
components could have been initialised out of order. In situations where
the anticipated order of execution was being relied upon this could
manifest visible errors such as catalogue filters from a shared URL being
incorrectly excluded.
This race condition has now been fixed and calls to require AMD modules are
now processed in advance of auto-initialisation.
TL-22610 Fixed error in HR Import when importing organisation or position custom fields when typeidnumber is mapped
When importing organisation or position custom fields using HR Import, if a
field mapping was used in the typeidnumber field an error would be thrown
causing the import to fail. This has been fixed.
TL-22622 Fixed an incorrect count of visible programs which led to missing pagination controls in the interface
This is a regression introduced by TL-22060 released in 12.10 last month.
The total count variable within prog_get_programs_page() was being
incorrectly populated after that change. It is now correctly populated.
TL-22632 Fixed the report builder default fetch method setting as its value was not being respected
TL-22658 Fixed the display of programs and certifications when folders are added to their image field
Folders are now ignored when added to the image field for programs and
certifications.
The ability to add folders will be removed in a future version by TL-22659.
API changes:
TL-22248 Checks to confirm a user can log in as another user are now performed by the user access controller
'Login as' permission checks have been consolidated into a new method on
the user access controller, \core_user\access_controller::can_loginas()
Existing checks within the product have all been converted to use this new
method, ensuring that the control checks are applied consistently.
TL-22392 Added course creation post definition and validation hooks
This change introduced two new hooks:
* \core_course\hook\edit_form_definition_after_data
* \core_course\hook\edit_form_validation
TL-22472 Removed incorrect use of $DB->sql_like() for non-unicode fields
SQL code executing LIKE statements on the context path in the database was
in some situations using sql_like, which led to collation management being
introduced. This was leading to an unnecessary overhead as path is a
calculated field for which we always know the character range used.
TL-22477 Active string filters per context are now cached using MUC
Previously a static variable $FILTERLIB_PRIVATE was used to cache active
filters by context during the lifetime of a request. This has been
converted to an MUC request cache, allowing for better management and
handling both in product and in our testing environments.
Contributions:
* Brad Simpson at Kineo US - TL-22243
* Davo Smith at Synergy Learning - TL-22518
* Peter Spicer at Catalyst EU - TL-22392
Release 11.20 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* [https://www.chromestatus.com/feature/5088147346030592] Cookies default
to SameSite=Lax
* [https://www.chromestatus.com/feature/5633521622188032] Reject insecure
SameSite=None cookies
TL-22408 Fixed two issues that could cause the tag name upgrade step to fail
As part of the fix for TL-21055 (introduced in 11.17, and 12.8), we
created an upgrade step to revert HTML-encoded tag names to their original,
non-encoded canonical state.
The upgrade step failed to take two conditions into account: multiple tag
instances on the same item that resolve to the same canonical tag; and
module tags that resolve to the same canonical tag as a course. In these
cases, the upgrade simply failed with a database exception.
The tags upgrade step has been rewritten to work properly in all
situations.
TL-22560 Improved the handling of conditional access restrictions that reference deleted items
Fixed a bug that prevented editing the access restrictions when a deleted
audience, position, or organisation was used as part of a restriction set
in them
We also made changes to stop removing course activity access restrictions
that refer to those deleted items.
In previous versions, whenever an audience, position, or organisation was
deleted, all access restrictions referring to the deleted item were
removed.
This could result in learners being able to access sections and activities
that they were unable to access before.
With this release, access restrictions are kept in place if the item(s)
they refer to are deleted. Such restrictions are updated to refer to a
'missing audience', 'missing position', or 'missing organisation', and will
prevent access to everybody until either removed or associated with a
different item.
Please note:
* If a 'missing' restriction is part of an OR condition, it will simply not
match rather than preventing access.
* If a 'must not' restriction is 'missing,' then learners who formerly met
the restriction condition will not be restricted any more.
* There is no way to recover access restrictions that were previously
deleted because they referred to deleted items.
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Improvements:
TL-22854 Fixed compatibility with PostgreSQL 12.0
Bug fixes:
TL-21828 Fixed Behat scenarios attempting to click on select input options after recent changes in Chrome
Recent changes in Chrome have led to sporadic issues through our Behat
features relating back to the definitions that attempt to click on options
within a select input. All affected feature files have been converted to a
method that works in all versions of Chrome.
TL-22207 Block permissions for authenticated users and guests are now restored corectly when restoring a course
In addition to the above noted fix the screen displaying information on
roles that cannot be mapped during restore now correctly displays built-in
role names and overridable roles.
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
TL-22401 Removed unnecessary use of set context on report builder filters page
TL-22435 Fixed context used for capability checks during goal userdata exports
Previously the goal exports were checking if a user could see their own
goals in the system context, however the capability is meant to be used in
the user context. This has been rectified where possible.
TL-22511 Deleting course completions either via the interface or via CLI now correctly purges completion caches
TL-22517 Fixed an error in first login tasks when a user has future assignments for multiple programs or certifications
If a user had multiple future assignments (due to setting a program due
date based on first login for a user who hadn't yet logged in), when the
first_login_assignments task ran, an error would be generated and users
wouldn't be assigned to the program / certification correctly.
TL-22518 Fixed email-based self registration with position, organisation, and manager while logged in as a guest
TL-22559 Seminar notification sender no longer reuses the sending user object
The reuse of the sending user object when sending notifications from within
the seminar occasionally led to an issue where notifications would appear
to come from random users. This has now been fixed by ensuring a fresh
sending user object is used for each notification.
TL-22576 All areas displaying a program or certification fullname are now formatted consistently
Prior to this change there were a handful of areas not correctly formatting
program and certification full names before displaying them. These have all
been tidied up and program and certification fullname is now formatted
correctly and consistently.
TL-22632 Fixed the report builder default fetch method setting as its value was not being respected
TL-22691 Changed seminar join waitlist button label from 'Agree and submit' to 'Join waitlist'
API changes:
TL-22472 Removed incorrect use of $DB->sql_like() for non-unicode fields
SQL code executing LIKE statements on the context path in the database was
in some situations using sql_like, which led to collation management being
introduced. This was leading to an unnecessary overhead as path is a
calculated field for which we always know the character range used.
Contributions:
* Davo Smith at Synergy Learning - TL-22518
Release 10.26 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* [https://www.chromestatus.com/feature/5088147346030592] Cookies default
to SameSite=Lax
* [https://www.chromestatus.com/feature/5633521622188032] Reject insecure
SameSite=None cookies
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Improvements:
TL-22854 Fixed compatibility with PostgreSQL 12.0
Bug fixes:
TL-21828 Fixed Behat scenarios attempting to click on select input options after recent changes in Chrome
Recent changes in Chrome have led to sporadic issues through our Behat
features relating back to the definitions that attempt to click on options
within a select input. All affected feature files have been converted to a
method that works in all versions of Chrome.
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
TL-22401 Removed unnecessary use of set context on report builder filters page
TL-22559 Seminar notification sender no longer reuses the sending user object
The reuse of the sending user object when sending notifications from within
the seminar occasionally led to an issue where notifications would appear
to come from random users. This has now been fixed by ensuring a fresh
sending user object is used for each notification.
TL-22576 All areas displaying a program or certification fullname are now formatted consistently
Prior to this change there were a handful of areas not correctly formatting
program and certification full names before displaying them. These have all
been tidied up and program and certification fullname is now formatted
correctly and consistently.
Release 9.37 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* [https://www.chromestatus.com/feature/5088147346030592] Cookies default
to SameSite=Lax
* [https://www.chromestatus.com/feature/5633521622188032] Reject insecure
SameSite=None cookies
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Improvements:
TL-22854 Fixed compatibility with PostgreSQL 12.0
Bug fixes:
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
TL-22401 Removed unnecessary use of set context on report builder filters page
TL-22503 Backport TL-22045: Login form is now only submitted once per page load
TL-22559 Seminar notification sender no longer reuses the sending user object
The reuse of the sending user object when sending notifications from within
the seminar occasionally led to an issue where notifications would appear
to come from random users. This has now been fixed by ensuring a fresh
sending user object is used for each notification.
TL-22576 All areas displaying a program or certification fullname are now formatted consistently
Prior to this change there were a handful of areas not correctly formatting
program and certification full names before displaying them. These have all
been tidied up and program and certification fullname is now formatted
correctly and consistently.
Release 2.9.47 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* [https://www.chromestatus.com/feature/5088147346030592] Cookies default
to SameSite=Lax
* [https://www.chromestatus.com/feature/5633521622188032] Reject insecure
SameSite=None cookies
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Bug fixes:
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
TL-22401 Removed unnecessary use of set context on report builder filters page
Release 2.7.54 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* [https://www.chromestatus.com/feature/5088147346030592] Cookies default
to SameSite=Lax
* [https://www.chromestatus.com/feature/5633521622188032] Reject insecure
SameSite=None cookies
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Bug fixes:
TL-22398 Fixed a potential problem in role_unassign_all_bulk() related to cascaded manual role unassignment
The problem may only affect third-party code because the problematic
parameter is not used in standard distribution.
Release 2.6.71 (25th October 2019):
Important:
TL-22311 The SameSite cookie attribute is now set to None in Chrome 78 and above
Chrome, in an upcoming release, will be introducing a default for the
SameSite cookie attribute of 'Lax'.
The current behaviour in all supported browsers is to leave the SameSite
cookie attribute unset, when not explicitly provided by the server at the
time the cookie is first set. When unset or set to 'None', HTTP requests
initiated by another site will often contain the Totara session cookie.
When set to 'Lax', requests initiated by another site will no longer
provide the Totara session cookie with the request.
Many commonly used features in Totara rely on third-party requests
including the user's session cookie. Furthermore, there are inconsistencies
between browsers in how the SameSite=Lax behaviour works. For this reason,
we will be setting the SameSite to 'None' for the session cookie when
Chrome 78 or later is in use. This will ensure that Totara continues to
operate as it has previously in this browser.
Due to the earlier mentioned inconsistencies in other browsers, we will not
set the SameSite attribute in any other browsers for the time being.
TL-22692 has been opened to watch the situation as it evolves and make
further improvements to our product when the time is right.
This change is currently planned to be made in Chrome 80, which we
anticipate will be released Q1 2020.
Chrome 80 is bringing another related change as well. Insecure cookies that
set SameSite to 'None' will be rejected. This will require that sites both
run over HTTPS and have the 'Secure cookies only' setting enabled within
Totara (leading to the secure cookie attribute being enabled).
The following actions will need to be taken by all sites where users will
be running Chrome:
* Upgrade to this release of Totara, or a later one.
* Configure the site to run over HTTPS if it is not already doing so.
* Enable the 'Secure cookies only' [cookiesecure] setting within Totara
For more information on the two changes being made in Chrome please see the
following:
* [https://www.chromestatus.com/feature/5088147346030592] Cookies default
to SameSite=Lax
* [https://www.chromestatus.com/feature/5633521622188032] Reject insecure
SameSite=None cookies
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Release 2.5.77 (25th October 2019):
Important:
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Release 2.4.73 (25th October 2019):
Important:
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.
Release 2.2.75 (25th October 2019):
Important:
TL-22621 SCORM no longer uses synchronous XHR requests for interaction
Chrome, in an upcoming release, will be removing the ability to make
synchronous XHR requests during page unload events, including beforeunload,
unload, pagehide and visibilitychanged.
If JavaScript code attempts to make such a request, the request will fail.
This functionality is often used by SCORM to perform a last-second save of
the user's progress at the time the user leaves the page. Totara sends this
request to the server using XHR. As a consequence of the change Chrome is
making, the user's progress would not be saved.
The fix introduced with this patch detects page unload events, and if the
SCORM package attempts to save state or communicate with the server during
unload, the navigation.sendBeacon API will be used (if available) instead
of a synchronous XHR request. The purpose of the navigation.sendBeacon API
is in line with this use, and it is one of two approaches recommended by
Chrome.
The original timeframe for this change in Chrome was with Chrome 78 due out
this month. However Chrome has pushed this back now to Chrome 80. More
information on this change in Chrome can be found at
[https://www.chromestatus.com/feature/4664843055398912]
We recommend all sites that make use of SCORM and who have users running
Chrome to update their Totara installations in advance of the Chrome 80
release.