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.
Groundwork for version support per offering - CUR-2673, CUR-2674, CUR-2672
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.
This release the technical groundwork is 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.
For the next release the user experience will be adjusted to ease the creation of a version by a user. Then also the various new configuration options and the behaviour in year roll-over will be explained.
Educational tasks should support display per period or per offering - CUR-3441 (Hotfix)
The previous release a change has been made to support display of the Educational task per offering. With the intention to provide a more detailed overview per offering, e.g., location. This extended detail was not expected and desired by all customer. The original grouping per period was in some cases the desired visualisation.
To support both visualisation the task definition is extended with an option to define the used grouping method. The default behaviour will use the grouped per period, as it was prior to the previous release. The added configuration option can be used per task template to use the offering based display option.
Configuration:
- Open the administration -> educational tasks menu
- For the tasks that can be bound to offerings and the grouping is not desired set 'Separate offerings'
Predefined facilities should be visible on the activity-card - CUR-3412 (Hotfix)
The predefined facilities were no long shown (or at least the data) on the activity card. This has been fixed, so both the label and data are shown for the predefined facilities.
Activity series should not shown an error from other offerings - CUR-3420 (Hotfix)
The validation of data uses in activity series could cause an error not directly related to the offering being managed. This was due to an issue in the validation routine, and is fixed so errors are only shown in case there is an error in the activity-serie being managed.
As a user it should be possible to impersonate another user - CUR-3397 (Hotfix)
The user impersonation was broken and caused a 'server error' when selected. This has been fixed, so if you feel the need to impersonate this is possible again.
Various small usability / user interface issues - CUR-2706, CUR-3339, CUR-3256, CUR-3402, CUR-3424, CUR-3433
- When adding a period, after save the added period is directly shown in the period overview
- The effort template information for numeric values is correctly (right) aligned
- Deletion of a new item is possible without showing an error after a successful delete
- Various messages containing 'unexpected JSON' solved, so the information requested is shown again.
- Highlighting the applied changes to descriptions including formatting in history mode is corrected
A generated field using a formula should be saved - CUR-3401
A custom field using a formula to define the value in a offering context was not saved. This was caused by the formula in the UI was properly executed based on the information at hand, but at save the calculation is performed in the back-end and there the root of the offering information was not correctly set.
A change is made to the validation of the formula and the option to identify a field is bound to an offering. By prefixing the value with offering to specifically define the offering should be used, e.g. take(:(offering)periodId, 2) to use the first two characters of the period for the specific offering.
Roll-over per faculty should keep relations bound to other faculties - CUR-3423
In case a roll-over is performed per faculty, all programs and its related data living within that faculty are rolled over. In case a faculty is rolled over with for instance program relations to modules to another faculty those relations and modules are not copied over.
As a user I want to be able to define a offering period that is before the module start date - CUR-3256
In the previous release support for adding methods to a module where the offering period was starting prior to the module start date. This was only added for methods, and has now been added to the appraisal too.
Configuration:
- Open or create a page based on the appraisal page template
- Set the checkbox 'Ignore validation', to support users to proceed when validation fails.
Datetime parameter should be respected - CUR-3368
The configuration supports the definition of the date (time) format to be used when showing date information. It was noted that defined datetime format was not respected in all cases, especially when entering data the datetime was not adjusted to the configured setting. This has been fixed, and the configured datetime is respected in all cases.
Creating a calendar should not cause an error - CUR-3411
When creating a new calendar and not setting the external ID an error was thrown. Since the external ID is required in the database, the data entry page is modified to require the external ID. The user can now only create (save) a new calendar when all the required fields, including the external ID are set.
Data should not be duplicated on save - CUR-3436
It was found that when using a slow network the save button could be clicked multiple times during the save action. This could cause duplication of the data being saved. A change is applied that will disable the save button while the save is in progress. This will prevent the user to click the save multiple times and cause creation of duplicate data.
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.
During this release no changes are made that affect the API(s).
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.
During this release no security issues needed mitigation.
Refer to the Curriculum manual for configuration guidance.