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.
Versioning update
Two releases ago we introduced the concept of versioning on beta. Since then a couple of customers tested the functionalities. Based on those we made several changes and improvements. We are at a stage we decided to make versioning part of the standard release process from now on. So as part of this release we’ll add versioning tot he main release. Does the mean versioning is completely ready? No, there are still a few more tickets we'll pick up in the coming sprints.
Based on the feedback received we made the following changes improvements related to versioning:
Create a new version while working in a study, module-group or module maintain process - CUR-4093
Previously, creating a new version of a study, module-group or module required leaving the maintain process for that object. A "create new version" option is now available directly from within the process. This can be enabled by using a new versions page template that lists all versions of an object and marks which ones are active. The example below shows all versions of a module and the + button to create a new version based on an existing one.
Copy activities from a previous version when creating a new module version - CUR-4010
When a new version of a module is created, the offering was copied to the new version but its activities were not. It is now possible to copy activities from a previous version’s offerings into the new version.
The copy can be made from the activity grid or the activity list page (that didn't change). The amount on the printscreen below shows the amount of activities you're about to copy.
Appraisal, assessment, method and method schema data now follows a versioned module correctly - CUR-4098
When a module uses versioning, its appraisal, assessment, method and method schema data isexpected to remain visible in every academic year the version is active in. This has been fixed,so this data is no longer tied to a single academic year when the parent module is version-based.
As an Admin I would like to use the definitionId to generate a code - CUR-4112
This work item involved defining and implementing a formula for generating study codes based on :definitionId. This is now made possible.
Add the field ‘definition’ to reports - CUR-4085
Reports on study, module-group and module can now include the definition as a column. The way to add the column work as it always works. The example below shows the definition column at module level (showing code and name of the definition):
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.
Changes report doesn't show the actual changes - CUR-4141 (Hotfix)
A role with permission to view changes could open the Changes report but didn't see the actual changes. This has been fixed, a user with the required permission now sees the changes again.
Link types now only offer objects matching the configured source and target type - CUR-3865
When configuring a link type, the object picker could in some specific scenario's offer objects of any type, regardless of the source and target type set on the link type. This has been fixed, so only matching objects are offered.
Faculty and Organization now expose the same Delete options as Study - CUR-4046, CUR-4060
The Delete and Delete (+ History) buttons available on for example Study were missing from the Faculty and Organization admin pages. On top of that, permanently deleting a Faculty or Organisation that was still referenced elsewhere (for example a module using that Organisation, or a Faculty with a configured process) failed with a server error, because the cleanup behind a permanent delete did not clear every reference. Both have been fixed: Faculty and Organization now show the same Delete and Delete (+ History) buttons as Study, and permanently deleting a referenced Faculty (including faculty parameters) or Organisation no longer fails.
Method-report now offers a facultyId column - CUR-4096
The method-report did not offer facultyId as a column, unlike the assessment-report. This has been added, and organisationId and studyId (already usable as filters) are now also available as report columns as well.
New module-groups now show the relational ‘required’ field on creation - CUR-4163
Adding a module-group or a module in the structure creates two things: the object itself, and the structure relation that places it under its parent. Those relations are study to module-group, module-group to module-group, module-group to module, and study to module, and they carry their own fields, such as Required, Phase and Cluster.
A create page is a page of route form, configured under Pages and selected as the create page on a custom type. It decides which fields a user is asked to fill in.
What it used to do. The modal showed the visible object fields or the create page fields, plus the relation field Required. That list lately drifted away from what was configured: institutions reported that Required was no longer offered on the New tab, and a create page on the module-group left the relation fields out altogether.
What it does now. There is no fixed field list anywhere. Each half of the modal resolves on its own, by the same rule:
the create page configured on that type — or, when there is none, every visible field of that type.
No create page on either half: all visible object fields, plus all visible relation fields.
A create page on the object type only: the fields on that page, plus all visible relation fields.
A create page on the structure relation only: all visible object fields, plus the fields on that page.
A create page on both: exactly what is configured, on both halves.
Each section is headed with the type and the create page its fields came from, this clarifies if a remark is for the object, or the relation. A section with nothing configured on it, neither a visible field nor a create page with fields on it, is left out rather than shown empty; for the study to module relation, the relation itself is then not created either!
The same modal is now used from the structure page, the study cost page, the planboard, the dashboard, and the module and group reports. The planboard does not offer the study to module section for now.
Adding a group from the structure page: one section for the group and one for the study to module-group relation, each named after the create page it came from
New in this release
Create pages on structure relations, through the new Entity type setting on a form page, so the whole modal can be configured. Make sure to set the Page is usable for field too.
The study to module relation is offered as a section of its own.
Alternative, Sequence, Description and any custom field defined on a relation can now be shown in the create modal. The relation half used to be fixed to (if visible) Phase, Cluster and Required.
Edit in structure on the study cost page. A new page option, showEditInStructure, off by default, adds it to the row menu and opens the same relation modal the structure page uses, just to align the pages a bit more.
The Version tab appears on the dashboard and on the module and group reports when versioning is enabled.
The Entity type setting on a form page
Changes to be aware of
Modules and module-groups show every visible field when no create page is configured, instead of the old five (code, local name, English name, type and Copy from). The modal can be considerably longer than before.
Credits and additional fields are no longer offered automatically. Credits used to appear whether or not anyone had configured them, this is no longer the case. You must now configure these fields through a create page.
Study, faculty, organisation, qualification, rule, specification and other types' behavior is out of scope of these changes.
Needs action
1. Configure a create page on the module and module-group types to control which fields are asked at create time, including if desired credits and additional fields. While you can also review on just the visible fields, this is intended as a fallback.
2. Add Copy from to the create page of every versioned type, or make it visible on the type where no create page is used. Without it, a new version cannot be created. Note that for now, the create page for New and Version are the same, so you might want to add a tooltip when to fill it in. We might revisit this later.
Extra fixes
One comment covers the object and all its relations. Every type has its own Comment type setting and the strictest decides: optional on a relation makes the comment field appear, required makes it mandatory. This now also holds when placing an existing module-group or module, which previously saved without asking even where the relation was configured as required.
A new version needs Copy from. Where that field was unavailable, the Version tab used to create an object that looked like a version but was related to nothing. It now refuses and says why: either Copy from is not enabled on the create page of the type, or it is not configured as visible on the type.
The Existing tab matches the New tab. It resolves its relation fields in the same way and notes that the values entered apply to all selected objects. The selection is now first, then the relation fields. Alerts were added to explain that the relation fields apply to the full selection.
Groups already on that level are left out. Selecting one again and saving cleared the relation data that had already been configured for that placement. Only the level being added to counts: a group can still be reused under year 1 and again under year 2, a group used deeper in the structure stays on offer, and a group whose placement was removed is available again.
Alternative on a module saves. A spelling mistake in the field name meant it was never stored.
The phase is saved from the study cost page. That page built its save without the phase, so a phase entered there was silently dropped; the same phase entered on the structure page was stored correctly.
The planboard now saves descriptions again
This is a large change to a screen that is used every day, so we would very much like your feedback on it. Please reach out if something does not work as you expect, or if you feel it should be tweaked.
An example configured
At group level we linked create page:
Study - Module Group level we did the same:
This two pages are then combined as following:
Some pages show an access-denied message instead of an empty page when a view permission is missing - CUR-4202
Several migrated pages (including the changes report, changes list, link list, assignments report, competences report, applicants report and workload study report) did not enforce the view permission, so a user without permission could see a blank page instead of a clear message. Each of these pages now requires the same permission and shows an access-denied message when that permission is missing.
It could happen pages showed an error when an assignment had no Organisation - CUR-4207
An assignment or vacancy could end up without an Organisation, which caused a server error on various pages, including on navigation between faculty pages. This has been fixed: the UI now rejects saving an assignment or vacancy without an Organisation, and existing data missing an Organisation no longer causes a crash.
Change report details now open in a drawer instead of a modal - CUR-4105 + CUR-3053
Clicking a row on the change report previously opened the change details in a modal. It now opens in a side drawer, matching the updated design, with general information, the change itself, comments and status transitions grouped into clearly titled sections, and review actions moved to the drawer header.
Migrated Reports: several changes - CUR-4137 + CUR-4152 + CUR-3195
Several reports have been migrated this sprint. Following the migration of the changes, assignment, competences and applicants reports to, the column selector was missing several capabilities the previous version had. Select all/deselect all (per column group), drag-and-drop reordering of selected columns (including full keyboard support), and an indicator for which group a selected column belongs to have all been added back. Sort direction now shows as an indicator on the sorted column itself instead of a separate row.
Person-report now offers an organisationId column - CUR-4095
The person-report did not offer organisationId as a column, even though the field is available as a custom field elsewhere. This has been fixed, and organisationId is now available as a report column, alongside facultyId.
Default result size for migrated forms increased to 250 - CUR-4155
Search results in the typeahead pickers used throughout the migrated forms have been increased from the previous default to 250 results.
The Faculty.organisations route didn't give any results - CUR-4097
The faculty.organisations route returned a tab with no data, unlike the equivalent faculties.faculty.organisations route. This has been fixed.
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.
Offering start and end dates were not applied when importing via the canonical integration - CUR-4193
An offering’s start and end dates sent through the canonical integration were read from the wrong place internally and were never applied — they stayed at their previous value regardless of what was sent. This has been fixed, and an imported offering’s start and end dates are now applied as sent.
Needs action: if your integration sends offering start and end dates, those dates will now actually be applied, where previously they were silently ignored. Please verify the dates you send are correct before this release reaches production, since previously-imported offerings will start picking up the sent values instead of keeping their existing ones.
New API endpoint for managing offerings independently of the parent module - CUR-4188
A new canonical endpoint (/api/import/v2/offering) is available to create, retrieve and delete offerings without having to resend the entire parent module.
Group type filter support added for study/module-group/module integration - CUR-4170
The integration for defining a group now supports a filter-based group type, in addition to the existing explicit lists of modules and groups (modulesFilter and groupsFilter).
Route endpoint can now be filtered by study - CUR-4088
The route endpoint (/api/import/v2/route) previously always returned routes from every study. It now accepts an optional study parameter to filter the results to a single study.
Export log no longer shows a misleading error when activities send successfully - CUR-4082
Exporting a module to the Activity Manager / Data Manager integration could show an error message in the export log even though the data had already been sent successfully. Every offering with a configured template now sends a request as part of the export, including offerings with no activities, so previously-sent activities can be cleared from Data Manager on a resend. As a result, an offering with nothing to export now shows as a plain ‘Completed’ rather than the ‘No request’ status the previous integration showed for the same case.
Next to generic tickets there are a few versioning related integration tickets:
New API endpoint for managing definitions - CUR-4191
Managing definitions can be done via the existing reference endpoint (/api/import/reference) . A newly created type 'DEFINITION' is available to create, retrieve and delete definitions directly, rather than relying only on automatic creation.
Version added to the canonical for study, module-group and module - CUR-4190
The canonical integration now exposes a version indicator (version) on study, module-group and module, alongside the existing definition field, for tenants using versioning. The previous metadata.versionNumber field remains available for existing integrations.
API support for delivering a plain string as definitionId - CUR-4169
Where an integration only has a definition identifier available as a string, rather than a full definition object, that identifier can now be passed through as-is.
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.
No updates this release.
Refer to the Curriculum manual for configuration guidance.