Hello everyone,
The following versions of Totara have now been released:
- 2.9.6.1
- 2.7.14.1
These release replace the 2.9.6, and 2.7.14 releases made earlier this month.
The reason for this emergency release is due to a potential dataloss issue with the upgrade step present in the Face-to-face module, introduced in 2.9.6 and 2.7.14.
For more information please read the following changelogs.
Kind regards
Sam Hemelryk
Release 2.9.6.1 (26th April 2016):
Important:
TL-8846 Face-to-face upgrade restores the latest non-empty signup and cancellation custom field data
The 2.9.6 release contained a fix for TL-6962 which was not acting in a way
that all users wanted it to.
Given an upgrade step is non-reversible, we have put out an emergency
release to allow administrators to choose how they want the upgrade to
behave.
TL-6962 was fixing Face-to-face signup and cancellation custom field data
being lost when the user's signup status changed.
The root cause of that issue is that custom field data was being stored
against the user's signup status rather than the signup itself.
Because a user could pass through multiple statuses, this data was lost in
the user interface as soon as the user's status changed. This was most
commonly seen if manager approval was turned on, in which case the signup
note entered by the user when they signed up would be lost when the manager
approved them.
The solution was to change this, so that data is stored referencing the
signup rather than the signup status.
This ensures that the data is maintained throughout a user's signup,
regardless of which statuses they pass through.
During upgrade we had to remap existing data and a choice had to be made.
Either we kept the data consistent with what users had previously seen in
the system OR we restored the last non-empty value for the field for each
signup.
We chose in 2.9.6 to keep the data consistent with what users were seeing
prior to the upgrade.
Since the release we have had feedback that this is not what all sites
expected and that they would prefer to have the last non-empty value
restored.
We appreciate this request and have come up with a solution that will allow
each site to choose, if they wish, which they would like to happen.
There is now a special configuration variable that can be defined in PHP to
change the upgrade behaviour.
The following explains what this upgrade step does and how to choose the
alternative behaviour if you want it.
Default upgrade behaviour:
The upgrade finds the last non-empty value for each Face-to-face signup or
cancellation custom field and uses that as the value the user entered.
This is consistent with the behaviour you will see AFTER upgrading to this
version.
It is not consistent with the previous behaviour before upgrading, which
was not maintaining the value the user entered.
This is the default behaviour so you don't need to do anything except
upgrade.
Alternative upgrade behaviour:
Instead of the default behaviour, restore the latest value recorded for the
Face-to-face signup or cancellation field, which may be empty due to status
changes, and store that as the user's current value.
This is consistent with the behaviour prior to custom fields being fixed.
It is not consistent with the current behaviour which ensures the value the
user entered is maintained.
To get this behaviour you must add the following to your config.php before
upgrading to 2.9.6.1:
$CFG->facetoface_customfield_migration_behaviour = 'latest';
If you have already upgraded to the 2.9.6 release the alternative behaviour
would have already been applied as this was the only behaviour available in
that release.
It is possible to change from the alternative behaviour to the current
behaviour if you have a backup from prior to the upgrade.
If this is you please get in touch with us and we'll provide instructions
on how to re-run this part of the upgrade using the data in the backup.
Release 2.7.14.1 (26th April 2016):
Important:
TL-8846 Face-to-face upgrade restores the latest non-empty signup and cancellation custom field data
The 2.7.14 release contained a fix for TL-6962 which was not acting in a
way that all users wanted it to.
Given an upgrade step is non-reversible, we have put out an emergency
release to allow administrators to choose how they want the upgrade to
behave.
TL-6962 was fixing Face-to-face signup and cancellation custom field data
being lost when the user's signup status changed.
The root cause of that issue is that custom field data was being stored
against the user's signup status rather than the signup itself.
Because a user could pass through multiple statuses, this data was lost in
the user interface as soon as the user's status changed. This was most
commonly seen if manager approval was turned on, in which case the signup
note entered by the user when they signed up would be lost when the manager
approved them.
The solution was to change this, so that data is stored referencing the
signup rather than the signup status.
This ensures that the data is maintained throughout a user's signup,
regardless of which statuses they pass through.
During upgrade we had to remap existing data and a choice had to be made.
Either we kept the data consistent with what users had previously seen in
the system OR we restored the last non-empty value for the field for each
signup.
We chose in 2.7.14 to keep the data consistent with what users were seeing
prior to the upgrade.
Since the release we have had feedback that this is not what all sites
expected and that they would prefer to have the last non-empty value
restored.
We appreciate this request and have come up with a solution that will allow
each site to choose, if they wish, which they would like to happen.
There is now a special configuration variable that can be defined in PHP to
change the upgrade behaviour.
The following explains what this upgrade step does and how to choose the
alternative behaviour if you want it.
Default upgrade behaviour:
The upgrade finds the last non-empty value for each Face-to-face signup or
cancellation custom field and uses that as the value the user entered.
This is consistent with the behaviour you will see AFTER upgrading to this
version.
It is not consistent with the previous behaviour before upgrading, which
was not maintaining the value the user entered.
This is the default behaviour so you don't need to do anything except
upgrade.
Alternative upgrade behaviour:
Instead of the default behaviour, restore the latest value recorded for the
Face-to-face signup or cancellation field, which may be empty due to status
changes, and store that as the user's current value.
This is consistent with the behaviour prior to custom fields being fixed.
It is not consistent with the current behaviour which ensures the value the
user entered is maintained.
To get this behaviour you must add the following to your config.php before
upgrading to 2.7.14.1:
$CFG->facetoface_customfield_migration_behaviour = 'latest';
If you have already upgraded to the 2.7.14 release the alternative
behaviour would have already been applied as this was the only behaviour
available in that release.
It is possible to change from the alternative behaviour to the current
behaviour if you have a backup from prior to the upgrade.
If this is you please get in touch with us and we'll provide instructions
on how to re-run this part of the upgrade using the data in the backup.