Improvements
The issues mentioned under the section improvements are considered as new functionality, user experience improvements and bug fixes.
Issues marked as Hotfix have been developed during this Sprint release, but are hotfixed and technically added to the previous release or direct to production based on the impact of the issue.
The styling should be consistent - CUR-1986, CUR-2004 (Hotfix)
Due to the migration to using a different UI components the visualisation of some screens and components was not as clean and crisp as it should be.
- In some cases the content of the page was not shown in a clean white area, but was partly shown in the blue footer. This has been fixed in all cases identified.
- The date-time component could cause a loop when reloading or refreshing the page.
Expressions used on specification should be year dependant - CUR-1959
When using expression on fields at specification level, the academic year was not respected, the values and operators used in the expression always used the first year the specification was created. This has been solved, so the year will be respected in expressions.
The edit/create button for references should not disappear from the screen - CUR-1929
In case references were defined with a long definition, the definition display was not truncated causing the buttons to manipulate the reference were moved outside the screen. This has been solved to limit the shown length of the condition, so the various buttons are always visible.
Offering pattern should be shown correctly - CUR-2000
In the previous sprint a pattern has been added to the offering to support configuring the display. There was an error in the shown formula example. This has to be:
- join(:name, ' (', :(offering) location, ')') (instead of join(:name, ' (', :location, ')')
Next to that the pattern was only used in the structure tree. This has been extended and the pattern will now be used in all pages showing offering information.
Add filter to subject matrix to support filtering on directly assigned subjects - CUR-1952
In case a subject (learning outcome / skill) is assigned to a module, based on configuration the module/subject combination can be assigned to specific programs. This means the module can have subjects that are just defined, and subjects that are defined and related to one or more programs. If a module has different subjects, they can be assigned to different programs.
The standard behaviour of the subject-matrix is that all modules and their subjects are shown if the module is part of the program. The new added filter allows for filtering to only show the modules that have a defined relation with the program at subject level.
Module sorting in program overview is incorrect - CUR-1964
Due to the change with the offering pattern the filter order for modules in the program overview (structure) didn't sort correctly on period. This has been fixed, so the sorting is as it was before
Add support for Finnish - CUR-1967
A new language pack to support Finnish has been made available.
Column headers should be shown more compact - CUR-1977
The display of the column headers was broken, showing the column header and its options spread over 3 lines instead on a single line. This has been fixed.
Dashboard tasks should be shown more compact - CUR-1978
The display of the dashboard tasks was broken, showing the task information spread over 3 lines instead on a single line. This has been fixed.
Date information shown on a form page and admin tab should be equal - CUR-1961
There was a difference in displaying (and storing) dates between the admin tab and the form tab. This has been fixed.
When deleting a task, this should be removed - CUR-1943
When deleting a task from a persons assignment list a message was shown 'task successfully deleted', but not in all cases the task was actually deleted. The cause has been found and fixed, so it's now possible to delete the tasks.
Performance
The main focus for this sprint was on the performance issues reported when using extensive Workload Management based on large numbers of activities and using the Teaching structure / Schedule preferences screens with large numbers of activities (>200). A deep dive is done to find the cause and solutions to tackle these performance issues and give expected response times in these cases.
Activity hour and course budget calculation should not give server timeout on calculate - CUR-1921
There were indeed cases the server ended with a server timeout, depending on the number of activities and lecturers to be calculated when hitting the calculate button. The processing and calculation method has been improved and for the provided real-life cases that showed this behaviour the response is change from 'server timeout' (60 seconds) to an almost instant response.
The activity report should provide proper response when filtering - CUR-1860
When using the activity report at faculty or program level having hundreds or even thousands of activities the behaviour was to always retrieve all data and then show the screen. At that moment the user could use the filter to select for instance the activities from a specific program or module(s).
Besides the performance changes in retrieving the activity information the page has been changes slightly. The user is first asked to provide a filter, since in most cases a filter list is required, before fetching the activities page by page. This will immediately give a proper response in a much shorter timeframe, and thus improving usability and user experience. The user can than filter within this subset.
The activity report performance should be improved - CUR-1981
When retrieving the activity report, the performance was not good with high numbers of activities. This was caused by the fact the activity list validated each activity shown on validity. Where validity is the check if all required fields are defined on the activity. This could lead to a lot of checks.
In a proper designed process, the activities should be created correctly. The main role of the activity report is to provide an overview of the activites and manage the shown activities. This task does not require a full validation of each activity.
Since there are cases a full validation is still required, and there are cases the validation should not bother the function executed at that moment a configuration option is added to support 'validation' and 'no validation'. The default behaviour is 'no validation', by checking the option validate the validation behaviour is activated.
Reduce the requirement to use individual activities - CUR-1858
Part of the performance issues are caused by a huge amount of activities. The original design is based on activity-series that contain activities. This leads to a reduced number of object compared to single activities and has the benefit of keeping track which activities are related.
Due to the fact activities in an activity-serie should all be the same (except for the activity week), in case for instance the title of an activity in a serie was used to express to students the content of the activity this was not possible. The fall-back in this case was to create all individual activities. Leading to a usage of the system in a non-anticipated way, with the mentioned drawbacks.
Based on the analysis a change has been made to stimulate and improve the usage of activity-series. The change applied is that activities within an activity-serie can have a different name and remark (multi-lingual).
Retrieving the effort-list performance should be improved after recalculation - CUR-1951
The retrieval of the effort-list after a recalculation could take quite some time, depending on the number of tasks and staff assigned. The calculation, refresh of the information and retrieval of the information have all been revised and changed to provide a proper performance.
Integration
The issues mentioned under the section integration are considered as extension, improvements or bug fixes related to the Curriculum API, OOAPI and/or CSV import functionality.
Gradually stop support for Basic Authentication - CUR-2001
As part of the migration from all test and acceptance environments to the shared TimeEdit Google stack, the support for authentication using Basic Authentication will be reduced. Existing configurations will be supported, but the advise is to migrate the interfaces using Basic Authentication will be migrated to using Bearer tokens for authorisation.
No action is required, but be aware that new integration requiring authentication will only support Bearer Token.
Extend API and CSV support for standard routes - CUR-2001
Some time ago support to define and use standard routes for curriculums is added. A standard route provides a way of defining multiple routes with an advised path for students including modules, period and advised year. This can be used to provide specific info for September and February start, but also a route for a specific qualification or diploma.
Support for CSV upload is added, where the documentation is available via the Administration / CSV menu option.
Support for API upload and retrieval is added, using the endpoint route. The implementation details are available in the API documentation at https://timeedit.readme.io
Security
An integral part of our develop and build processes is automatic scanning for known security vulnerabilities. The vulnerabilities will be fixed based on their impact, which means that in some cases an immediate hot-fix will be applied, and in other cases the vulnerability will be fixed in the current or next Sprint (release). The security section provides an overview of the vulnerabilities mitigated.
This release mitigates the following vulnerabilities:
- CVE-2025-49146(8.8)
CVE-2025-22233(2.29)- CVE-2025-41232(9.3)
CVE-2025-41234(7.4)- CVE-2025-48988(7.5)
For more information on reported vulnerabilities, see the central database of vulnerabilities.
For more guidance on configuration and setup of Curriculum, use the relevant Curriculum manual.