24 February 2025

Submissions release notes

The release notes detail the new features, bugs, and known issues in release 2025.02.

Features

The table Features details the new features in release 2025.02.

Features
Reference	Header	Business impact	Affected topics
325177	New delete notifications permission	A new permission has been added to the Submissions area. This permission controls roles that can delete notifications in the Notifications user interface. The following roles have the permission to delete notifications as follows: Edge Administrator: granted by default, permission cannot be removed. StatutoryAdmin: granted by default, permission cannot be removed. Statutory: granted by default, permission can be removed.	Submissions permissions
325218	Notifications automation - clearing down old notifications and CHESSN changes	Notifications will now be scheduled to automatically clear down nightly based on enabling the process in the Settings menu. The following rules generalise the process, but from a customer perspective, it is important to note the logic changes around CHESSN, SIS, and S2E notifications. Providers will already be seeing warnings in Submissions regarding the provision, update, or removal of a CHESSN. As such, this is the first feature that removes CHESSN processing from Submissions. Refer to the TCSI Support website for any concerns on ceasing reporting of CHESSN. Notifications delete logic For every notification in Submissions Notifications table: If notification category = SIS or S2E or CHE or CHA If date added greater than 7 days? Delete the notifications from Submissions Notifications table. If any of these appear in the user interface and are known to have been resolved, you can manually delete them. Otherwise Issue a B2G / notifications / <uid> call to retrieve the latest version of the notification. If response = 404 Delete the notification from Submissions Notifications table as the notification has been removed from TCSI. If response = 200 If the status = EXPIRED or RESOLVED or COMPLETED Delete the notification from Submissions Notifications table. Otherwise Update the notification in the Submissions Notifications table if differences exist. If any other response from TCSI Log the issue, ensuring that the request URL, header, request JSON, response and response JSON can be sent to TCSI Support. Overall outcome The overall outcome of the overnight clear-down is that the Notifications user interfaces should contain only outstanding notifications and should closely align with the TCSI Live Notifications report. If customers observe significant differences between the TCSI Live Notifications report and the Notifications listed in the user interface, please raise a ticket with Support. An example test run in a test tenant with 3.5 million notifications resulted in clearing down to six(6) notifications in total in the user interface, all generated within the last two days. Attention. Notifications status Tribal have raised the lack of notifications status updates on a given notification. For example, a TFN notification does not maintain its lifecycle as depicted in the TCSI Notification documentation. As such, the notifications status will not be maintained. TCSI Renewal Project have been informed of our requirement for adequate maintenance of a given notification status so that the solution can track the validation of TFN and USI moving forward. This issue will directly impact the TFN Verification Status work being undertaken within Submissions and future USI Verification Status work. Customers wishing to support the request for Notification status being accurately maintained against TFN and future USI notifications should raise a TCSI Support ticket requesting the status be maintained moving forward.	What are notifications?
358266	Notifications staging API - method addition	A DELETE method has been added to the Notifications staging API. This method is secured by the new permission added in this release. Attention. This method will not be accessible by integrating systems using the Staging API suite. Business rules on the method are applicable as follows: A user needs the delete permission for the delete button to be accessible, one or more notifications must be selected before the button is enabled. Only notifications with the following categories and status can be deleted: TFN with a status of Read, In error, or Expired. LLW, LRV, WRN, and VRJ with a status of Read. CHA, CHE, USI, SIS, and S2E regardless of status.	Not applicable
358267	Notifications UI updates	The UI for Notifications has been updated to allow a user with the correct Submissions area permissions, to select notification records and delete them from the system. This cannot be undone. It is suggested that users use the download feature to create a backup of the notifications where required. The user will be presented with a modal dialogue confirming the delete action. Users can confirm or cancel the action. A new menu option under the Submissions Settings menu has been created to enable or disable the nightly Notifications clear-down process. Enabling this will schedule the process to run at 2 AM AEST. Customers should be aware of this timeframe in case it impacts their integrations with Submissions. Two bugs have also been fixed: Inconsistent naming of the grid header record when toggling the column names between a data group and then switching to the Notifications page. Downloading an empty filtered result set returned a JSON error.	What are notifications?

Bugs

There are no bug fixes in release 2025.02.

Known issues

Notification status

As detailed in the note above, TCSI notifications do not maintain a lifecycle status as documented by the TCSI website. As such, some notifications may not be deleted automatically. Examples of this are the SVE and VER notification categories, where during our testing these notifications were not updated or deleted. This could be due to the extensive age of the data.

If resolved notifications are still present in the Notifications user interface, then users with the Delete Notifications permission can manually select and delete them permanently to complete the tidy up of the outstanding list of notifications. If the manual deletion of some of these categories is problematic, please raise it as a concern.

If you manage these types of notification categories using integration and internal reporting, the clear-down process can be updated in a manner similar to CHE, CHA, S2E, and SIS notifications. That is, remove the notifications automatically once the notifications are older than seven days — as detailed in the notification delete logic above.

Notification clear-down duration

Tests in a tenant with over three million notifications show that it takes many hours to complete the notification clear down. Although this was in a test environment, it still raises a risk. Therefore, customers with several million notifications should enable the Notifications Automation on a Friday. The clear-down process then starts at 2 AM on Saturday morning. Enabling the clear-down process on a Friday should reduce any impact on online users of the solution rather than if it runs during the week and it subsequently runs into business hours.

RTP scholarship data

This known issue will be removed from all future release notes due to its age and the understanding that impacted students may have completed their studies.

Issues with historical RTP scholarship data were found to cause issues with data migration. The root cause appears to be when RTP Scholarships in HEPCAT are created against reporting periods that are then migrated to TCSI as follows:

Reporting period one migrated as E609: 01/01/YYYY and E610: 30/06/YYYY.
Reporting period two migrated as E609: 01/07/YYYY and E610: 31/12/YYYY.

Problems have been found when attempting to match student management system data to the TCSI data due to the following:

Submissions RTP scholarships data migration not partially matching as expected (resolved in 2021.08 under AMS 850891).
Major discrepancies in the way that pre-TCSI RTP scholarship data is recorded in the student management system and then sent to Submissions. For example, the student management system has one RTP scholarship with a start date of 02/04/2017 and an end date of 30/10/2019; this record covers six reporting periods and cannot easily match to any of the RTP scholarships migrated from HEPCAT to TCSI.
Instances where Submissions has matched incorrectly to a TCSI RTP scholarship. For example, if a UID exists against an RTP scholarship but the attempted PATCH has resulted in a 10376 or 10430 error, the match will need to be removed by the Tribal support team before any remedial work can take place on the student management system data.

Note that it is possible to re-attempt the migration of the RTP Scholarship record once the parent Course admission has already been migrated. This should only be attempted where the TCSI data matches what has been sent to Submissions by the student management system to avoid the above issues.