The release notes provide information on the features and improvements in the specified version. The release dates that are related to the version of the release are published in the Curriculum/Workload Management release schedule.
Improvements
The issues in release mentioned under the section improvements are considered as new functionality, user experience improvements or 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.
Offerings should be shown on the module offering tab - CUR-3561 (Hotfix)
The module offering tab was not showing the offerings anymore after the previous release. This has been hotfixed on acceptance prior to the release to production. The offerings are shown again as expected.
Time information should be shown correctly - CUR-3560 (Hotfix)
Time information was not shown correctly, which could cause an effect that the time to display conversion ended up with an empty value (on screen) on activity-series custom-fields. This has been fixed, and the saved time information is shown correctly.
Date information should be shown in a date format - CUR-3539
Date information was not shown as date (YYYY-mm-dd), but as a timestamp. This has been fixed and the date is shown again in a date format.
The method tree should show empty values instead of 0 - CUR-3538
In case in the method tree (and also in other places) a numeric value was shown in a report, both a 0 and an empty value were displayed as 0. A fix is applied where an empty value is shown in case no information is entered and a 0 in case a 0 is entered.
The appraisal list shouldn't show the externalId twice - CUR-2165
In case the appraisal list was configured to show the externalId or code, they were shown twice. This behaviour has been solved in the case where the code or externalId are configured using the 'shown on general' setting.
Remaining known issue: In case the column option is used to add fields to the appraisal list AND the selected fields will contain externalId or Code they will still be shown twice. This is caused by the fact the code both lives on appraisal and assessment. To mitigate this requires a quit extensive rework of the custom-field resolution and will not be solved. The work-around is selecting the code and externalId using the 'show on general' setting.
When starting a new proces only the start notification should be sent - CUR-3579
In case a process step was configured to sent both a notification at start of the task (open) and a notification is the process was rejected to that step (re-open) both notifications were start at start of the process. The cause has been identified and fixed.
The hours per month should be correct - CUR-3451
The total available hours of a staff member is calculated based on the contract and the hours per year. The hours per month are based on a factor of this total per year. When showing the personal allocation information the factor is applied when switching from year to semester to month view. This to show the correct planned hours per selected period. The same factor was also applied to the available hours per period. This caused the effect that on Semester view the hours for January could be 141 and when switching to Month view the available hours were shown as 35 hours.
This has been fixed and the factor will only be used for the planned hours and not on the available hours.
Available hours should be updated after assign and recalculate - CUR-3504
The staff allocation and availability overview shows the actual assignment and availability of staff. In case changes are made in the allocation not in all cases the availability of the person is recalculated, this is standard done via the nightly re-calculation of all assignments and availabilities.
The report provides an option to execute a force recalculation, where the recalculation of the availability was only calculated after opening each user.
The behaviour was a 'quick-fix' precaution, since the recalculation could take quit some time. In this release a change has been made to this behaviour by implementing a 'targeted' recalculation:
- Change of a task and the hours will automatically recalculate the availability for that assignment
- Calculate will recalculate the availability for for all staff members and NOT the assigned hour calculation. The assumption is that the 'hours assigned' are correct. A loader will be shown in the availability cell and not on the entire page (blocking the entire page)
The calculation of available hours should support usage of 'remaining hours' - CUR-3298
The use case is as follows:
A person has an assignment of 1 FTE
The person has a non-educational task as Program Director covering 60% of the FTE
The person should be assigned with a 60/40 ratio to research and teaching for the remaining hours.
In this release the option is added to used a more dynamic definition of grouped tasks (labeled with the same label). The following mechanism is used:
- The label name is used as a ‘grouping’ mechanism to identify tasks that belong together
- A new dynamic calculated field is added to use the 'sum' of the grouped tasks. The naming convention is {label}Hours, where the label may not contain spaces, dots, dashes.
- Enable usage of the dynamic calculated field(s) in formulas
The initially mentioned use case can now be handled by defining the hours to be allocated for research with the following formula:
- 60% research of the remaining hours: (:fteHours - :coordinationHours) * 0.6
Offering based version support
The standard behaviour of Curriculum is the support of a version per academic year. E.g., a module is published once a year and during that year the module will be bound to that version. Changes could be made, but they would just overwrite the initial state.
Two releases ago we published the technical groundwork was done for support of multiple versions per year. A version will be bound to an offering, since this is the most logical publishable unit. This will support for instance publishing a version for a module for quarter 1 and a version for the same module for quarter 3.
The definition of changes allowed in a version and changes that require a new module are different per institution and are still applicable. This means that a version can also be a 'new' module. In case a module is offered in a program, the new module will substitute the 'old' one and a new program version is created based on the offering period.
The version support can not only be used for the regular programs following the standard academic year and its periods, but is also applicable to the more commercial oriented short programs or modules. In those cases an ad-hoc offering is used to support the distinct versions of a module between offerings.
After that we started developing the user experience and found out we had to redo the groundwork. Sometimes you learn that a in-depth design is not always perfect. A decision was made that a version is not a full copy of a module, but specific part of a module will support versioning. Module elements with version support are descriptions, additional fields (next release), offerings, teaching methods, assessments and activities. This is based on the fact that most (if not all) other changes will lead to a new module.
As an administrator I should be able to configure version support - CUR-2672
A new configuration option is added to enable offering based version support in the system.
Configuration:
- Navigate to the Administration -> Configuration menu
- Set the 'version.period_based' to true
As a user I want to create and view the available versions in its context - CUR-2675
The relevant pages in Curriculum (structure, planboard, module) are be extended to show if multiple versions are available. A user should be able to select and switch between versions that will then show the information for the selected version. The structure page will show the different version of a programme, the module details will show the different version of a single module.
In case offering-based version support is configured, the 'switcher' will be available and allow switching between versions. In case a version is selected and a change is made to the the object, the version is automatically created and the change is bound to that version.
The image below shows the version of a January start (a specific program offering/start) and in this case the curriculum will offer the full program in four years.
The image below shows the April start is a version that offers a changed curriculum. In this example a module-group is offered containing the standard supported specialisations.
The example is shown because of its visual simplicity, but any object in the structure tree can be moved, removed or added. For instance a change where a new module is added to be first offered in April.
A similar switcher has been added to the Module. The switcher will only be shown in case version support is configured AND the module has multiple offerings. As the image below shows the switcher in the workflow and allows selecting a version to be worked on.
If no version (or the first) is selected, the changes will be applicable from that version onwards. In case a change is made for the second period, a new version will be added. The version of period 1 and the version from period 2 onwards. In this case period 2 and 4. In case a change is made in period 4, again a new version is created and there will be 3 versions (period 1, period 2 and period 4).
Rollover to new year of the latest version - CUR-2677
The rollover will use the latest version of the selected year to rollover to the new year. In case no changes are applied, the initial version will be used. In case multiple versions are created, the latest version will be used.
Outstanding TODO's
Quit a big step is made and the function is made available on the test environment. There is still some work needed to polish the solution. Know outstanding work is:
- Extend support for versioning to additional custom-fields
- Improve UX behaviour (easy to find, toggle between version page refresh)
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.
Integration to Data Manager should support activity planning name fields - CUR-3564
The configuration for the integration to Data Manager didn't support usage of the planning name fields. This has been added and the configuration will now support transfer of the planning names using the planning.names['<lang>'] convention. E.g. planning.names['EN'] to exchange the English name.
Exchanging availability information to Core should support batch send - CUR-3549
An issue from a more technical background, that will also improve the through-put to Core. The availability information defined was sent to Core per availability moment (reservation). A change is made to group the availability exchange with 100 availabilities per request. This means the overhead of individual messages is reduced and handling of a single request with 100 availabilities will speed up the processing.
An event message should contain the object type sent - CUR-3526
When using the event to sent a changed object to an external integration service the event message doesn't have information on the object sent. Especially in situation where all events are handled by a single endpoint that will redistribute the further handling of the event to a dedicated handler (module, study, ...) this requires extensive analysing of the message sent to determine the object type and thus the handler.
The default message metadata is extended with the object type to ease the determination of the object type to be handled:
Enhanced and standardised the behaviour of the Broker integration - CUR-3417
The integration to the Broker was depending on the manner used behaving different. When using the 'send to Broker' hook, the object was sent including non-approved open changes. When using the script 'send to broker' to execute a nightly synchronisation based on the presence of an publication date. In that case the object was sent including any open changes.
The following changes have been made to standardise the behaviour:
- Added a Configuration option 'broker.include-open-changes' to define if the standard behaviour should be that an object was sent including its open changes, or only the approved data should be sent.The default (and recommended) setting is to not include open changes.
- Created a hook 'Approve open changes' to be used in the processes at the transition to the approval state. This will automatically mark all changes to the object as approved, so it can be sent to the Broker.
- Extended the hook 'Set publication date' with an additional option 'Approve'. In case the approve is set, both the publication date is set and the changes are marked as approved.
When adding a person it should be possible to define the organisation - CUR-3329
It was noted both the CSV import and the API person endpoint didn't offer support to add the organisation relation of the person. This has been adjusted and both CSV import and person API support the definition of the related organisation. The person GET is extended to show the person relation.
The adjusted API definition is available via: https://developer.timeedit.com/reference/saveperson_v2
Security
An integral part of our development and build process 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. For more information on reported vulnerabilities, see the central database of vulnerabilities.
In this version no vulnerabilities needed to be addressed.
Security vulnerabilities addressed:
- CVE-2026-29062(8.7)
- CVE-2026-29062(8.7)
- CVE-2025-68161(6.3)
- CVE-2025-29927 (6.5)
- CVE-2025-29928 (3.7)
- CVE-2025-29929 (5.5)
- CVE-2025-29930 (6.5)
- CVE-2025-29931 (6.8)
Refer to the Curriculum manual for configuration guidance.