Destiny Solutions is pleased to announce the launch of Destiny One’s Release 5.7!
Release 5.7 is now complete and will be made available to our customers over the coming days. The dominant themes for this release were staff and learner usability improvements. We also made excellent progress on the new Student Profile Templates feature, which we will continue to work on for the next few releases.
Erase Person Feature
To facilitate a user’s right to be forgotten, which is stipulated under the EU’s General Data Protection Regulation (GDPR) which came into effect in May 2018, a new Erase Person feature was added to Destiny One.
Three types of people can now be erased from Destiny One: students, contacts, and proctors. Instructors and staff cannot be deleted from Destiny One using this tool as those individuals have a contractual relationship with the school and are therefore not subject to the GDPR right to be forgotten.
The process by which the user who wishes to be forgotten makes the request to the school is offline and not managed by Destiny One. After a school administrator validates a user’s request, they can access that person’s profile to start the erasure process.
Three new permissions have been added to the Destiny One system to allow administrators access to the Erase Person feature from the respective profile type.
- Erase Student
- Erase Contact
- Erase Proctor
After clicking the “Erase” button, the system validates that the individual has no financial obligations (that is, no outstanding invoices or credit memos). If they do, the erasure is blocked, and those obligations must be settled before the erasure can be initiated. If the student belongs to a group with an outstanding invoice or credit memo, the admin must first remove the student from the group in order to proceed.
The Erase Person process is irreversible, so admins must take great care with whom they grant the permissions to access this feature. When executing an erasure, the system will ask for confirmation in the form of initials of the administrator. If the individual being erased is a youth participant, a second confirmation will be required from the administrator indicating that they have received the request to be forgotten from a parent or guardian.
Following submission of the confirmations, the system will obfuscate and/or delete direct and indirect personally identifiable information in Destiny One. Mandatory profile fields will be obfuscated with replacement text such as “Deleted” or “Deleted with a date/timestamp” or a one-way hashed value. All optional profile fields will simply be deleted. Any associated profile data and records will be deleted, not limited to: historical addresses, internal comments, profile holds, applications, references, uploaded file attachments, communications and tracked emails, program offering admissions, transaction line item notes, basket notes, marketing question responses, coursework file uploads, grading sheet comments, attendance sheet comments, student health insurance records, student financial aid tracking records, group and contact associations.
The Erase Person feature will not delete: financial transactions including enrollments, drops, transfers, voids, wait list, and special request purchases, grades, proctor exam bookings, PII data that may appear in hosted log files such as IP addresses (data in hosted log files will be deleted through normal purging and roll-over processes; schools with an on premise installation of Destiny One should implement appropriate log control processes), PII data that appears in standalone data import or export files external to Destiny One which is outside of Destiny Solutions’ control. We recommend that schools review their internal data processing guidelines to ensure that such files are purged on a regular basis.
After the Erase Person process has run, the person record will still exist in the database but the system identifier will be changed to a one-up number that cannot be traced back to the original person number. For students, all enrollments, financial transactions, and grades will continue to be attached to the student record, but any personally identifiable information will be obfuscated or deleted. Class rosters will continue to the erased record, but the identity of the student who enrolled will be unknown. For all person types, the erased person record will be changed to Inactive, which will preclude it from being returned in default search results for active records.
Website Cookie Consent Policy
Staff Ability to Edit Marketing Question Responses
Staff users will now see an “Edit” icon associated with a student’s or group’s supplied marketing question responses for transactions associated with enrollments or purchases. Clicking it takes them to a page showing all questions that were posed during that transaction. Staff users can also answer any unanswered questions associated to the basket.
New Enrollment Restrictions for Program Offerings
On the Enrollment Restrictions page you can now create an enrollment restriction rule that can be applied to program offerings based on student category and citizenship. The restrictions can be assigned to program offerings in bulk from the Restrictions page or individually on the CM > Programs > Offering Profile page using the Enrollment Rules subform.
Conference Manager Information Collection When Paying By Another Method
Previously, if a conference registrant opted to pay by another method, any answers that they provided to information collection questions may have been lost when the transaction was forwarded to a staff member for processing. This has now been resolved and any supplied answers will be maintained until the basket is processed by a staff member.
New Salesforce Connector Pipeline
This new pipeline is available to schools that license the Destiny Connect Salesforce Connector. We updated the Destiny Connect Salesforce Connector reference implementation to support a Creation event in Destiny One to push student information into Salesforce.
When a student record is created in Destiny One for the first time, an event will send the student record to SnapLogic, and then the pipeline will attempt to create that person as a new contact in Salesforce.
- If there are no potential matches in SF, the Contact will be created in Salesforce, and the Salesforce Contact ID will be sent back to update the student record in Destiny One. Any subsequent profile updates, initiated in SF or Destiny One, will trigger an update to the other system.
- If a potentially matching record already exists (using duplicate matching criteria), a duplicate resolution event will appear on a new page in Destiny One (Staff View, SA > Integrations > Duplicate Student Failure Resolution) where a staff member can (a) delete the event, (b) match the student to one contact in SF, or (c) force create a new contact in SF.
If that new student also completed an enrollment or a purchase, the corresponding Notification of Transaction would also be sent to Salesforce (which includes section, bundle, program offering, and conference enrollments).
Web Service Versioning
Starting with this release, we now support versioning of web services by using namespaces. Web services that were in place as of Destiny One version 5.6 have been maintained in namespace “v1”. Moving forward, when Destiny Solutions refactors existing services, they will be added to a new namespace so that both the legacy and refactored service will be accessible. With release 5.7, on the web service homepage, you will see two new namespaces: InternalViewServiceV2 and InternalViewRESTV2.
New & Enhanced Web Services
In release 5.7 we are adding the following new internal web services. These are available in web service namespace v2
We have also refactored the following web services to improve performance and add new capabilities. These are available in namespace v2:
- getStudent (the prior version still exists in namespace v1). v2:getStudent now has informationLevels defined, to return different amounts of data. Some attributes were removed from the student element, and a new container was added.
- searchStudent (the prior version still exists in namespace v1). v2:searchStudent is now paginated, with a maximum pageSize of 250. Some attributes were removed from the student element.
- createOrUpdateStudentFinalGrade (the prior version called setStudentFinalGrade still exists in namespace v1).
- See the Release Notes for other miscellaneous enhancements that we made.
PBKDF2 Encryption or Hashing
We have replaced our SHA-1 password hashing algorithm to PBKDF2, which is one of the one-way functions recommended by OWASP. Existing passwords won’t change to use the new protocol until they are changed by the user; but all newly created passwords will use the new protocol.
Our jQuery library has been upgraded.