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 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.
In-line module-group descriptions should support multi-lingual - CUR-2157
The structure page offers support to 'in-line' change the informative description for module groups, e.g. you have to select 6 credits from the underlying modules. This description field was available as a multi-value field, but only manageable at the module-group.
A change is made to support management of all supported languages direct from the structure page, instead of only one language.
Organisation report should support opening organisation details - CUR-2232 (Hotfix)
The navigation from the organisation report / overview to the underlying organisation details was broken. This has been (hot)fixed, to enable navigation to the visualisation and management of the organisation details via the organisation report.
Assessment related credits not shown - CUR-2225 (Hotfix)
Implementations using a self-defined custom-field to define assessment related credits didn't correctly show and validate the credits. The credits used to validate if the total defined credits on the assessments matches the defined credits at the module was always incorrect, since the assessment credits value used was 0. This was caused by the fact that the credits has been moved to a Curriculum default field, and the existing data for this implementation wasn't moved. For the implementations affected the existing data has been migrated to both show the correct credit value at assessment level and use this value in the calculation.
As a user I want to remove (shared) methods from the method-tree - CUR-2235 (Hotfix)
Due to a change in the previous version it was no longer possible to move a 'shared / lend' method from the method-tree that has lend the method from another module. This has been (hot)fixed, to support removal of lend methods again.
Only the owner should be able to edit an assessment - CUR-2295 (Hotfix)
In case an assessment was lend from another module, the lending module owner could change the activity-serie of the lend assessment. This has been fixed to only allow changing of the assessment and its activity-serie(s) by the owner.
As an administrator I want to lock management of an activity-serie for an offering period - CUR-2124
In case a module is offered twice a year, e.g. Semester 1 and Semester 2, and the process to manage the module activity-series is run twice a year, a user can both modify the information defined for Semester 1 and Semester 2. The requirement is that it should be possible to 'lock' (disable any editing) the defined information for Semester 1, when the process is run for Semester 2.
A configuration option is added to the Academic year - Period configuration to define a 'lock date' per Period. This allows for setting a lock date upfront, that will be used to enable editing of the activity-serie based on the selected period. In case the defined date is passed, the activity-serie will be locked and shown as read-only to the user.
Reset button shown for module with a changed code - CUR-2205
In case the module code of an existing module is changed, a 'Revert code' button is shown in the workflow of all stakeholders involved in the process that allows to revert the code back to the original code. The requirement is to not show the 'Revert code' button. To support the requirement, and additional configuration option is added to either enable or disable the showing of the 'Revert code' button in the workflow.
Configuration (Administrator -> Config menu):
- changes.show_revert_code = true / false
Deleted subjects should not be shown (in bulk select) - CUR-2187
When using bulk select on subjects, the deleted subjects at study / specification level were still shown. This has been fixed, so only the 'active' subjects are shown and available for bulk select.
The process manager should show all specifications in the selected year - CUR-2207
The process manager only showed the specification with a data equal or before the start date of the selected academic year. Specifications starting during the year were not shown. A fix is applied to extend the specifications shown in the process manager by validating if the specification is valid within the academic year. Thus validating if the start date of the specification is between the start and end date of the selected year.
Deleted offering periods should not be shown in the route planner - CUR-2159
In case a route (study path) is defined with the relevant offering and the offering is removed from the module, the offering was still shown in the route as if it was active. A change has been made to the route-planner to visually inform the user the defined route is using an invalid offering. Instead of 'not showing' the removed offering, the offering will be shown as 'strike-through' to indicate the original defined route for the module - offering combination is no longer available and requires a change.
As a program responsible I want to define module -> study relation information - CUR-2125
A feature request has been filed to support the definition of attributes on the module -> study relation. This would be similar to the module -> module-group relation, where you can define information specific for a relation between an individual module and a module-group. A practical example would be that module A is required in module-group B and not required in module-group C and D. The required attribute is in this case defined on the relation between a module and its module-group.
A similar option should be available to support the definition of information on the relation between a module and the programme offering the module. To support the definition and management of the module-study relations it is required that information can be defined and managed on the relation from a module with the offering programme. To offer a broader support then just the module-study relationship information the support will also take the module-group as part of the relationship. This allows for defining different values for an attribute in case a module is offered multiple times in a program, based on its module-group context.
In case a module is offered multiple times in a program, it is supported to NOT select the module-group. In this case the relationship information is the same for each occurrence of the same module in the program.
Added functionality to support the above is:
- Add support to define ‘relationship’ information of a module in context of a programme (study) and module-group.
- Add support for the administrator to define custom-fields on the module-study relation to be managed using this relationship.
- Extend the management of module-study relations for the user from the structure page by extending the module-module_group popup to support both module-group and study relationship information.
- When managing the module-study relation, ‘inherit’ the module-group containing the module. This to limit the user actions to solely selecting the study and setting the relationship information.
- Only provide the module-study relationship management information to the user if at least one attribute is defined by the administrator.
The image below shows the option to define the module -> module-group relation information (tab: Structure) and the module -> study relation information (tab: Relation (study/module)).
Configuration and management of offerings should support conditional fields - CUR-2087
Conditional fields are supported on (almost) all object, and so now and then we are pointed to an object that is lacking this support. It was noted that offering periods did support the configuration of conditions and conditional fields, but the visualisation didn't respect the configuration. This has been fixed, to support usage of conditional fields on offerings too.
Buttons to manage activities in the activity-grid should be accessible - CUR-2164
The activity grid shows a visual representation of the desired teaching layout (activities). The activity-series and activities defined can be managed using the buttons shown in the tile. However, in case a long(er) activity name was used, the name was positioned on top of the buttons, making them inaccessible. A change is applied to truncate the activity name and not float over the button. The button is now always accessible and the full name of the activity is available using mouse-over.
Reports using a row page should show the information when expanding the page - CUR-2204
In case a report page is defined that using a row page and the row page is configured to be collapsed by default, when expanding the page the row page information was not shown. A change is applied to retrieve and display the row page information on expand.
The planboard subject view should only show the subjects directly related to the study - CUR-2021
In all reports, except the planboard view, the subjects shown are filtered on the defined relation to the study. This 'direct related to study' filter is now also applied to the planboard view, so the behaviour of all reports is the same.
As an administrator / implementation manager I want to brand the used product - CUR-1993
The Curriculum and Workload management product partly use the same configuration and administration interface. Using the administration interface the 'branding' of the product can be defined and differentiate between the Curriculum or Workload management branding.
Configuration:
Navigate to the Administration -> Config menu option
- Set the 'header.workload-product' to true to use the Workload management branding
- Set the 'header.workload-product' to false to use the Curriculum branding
- Optionally set the 'header.product-switcher' to activate the TE product switcher including the branding selected
Usage of images in descriptive texts should be more robust - CUR-2200
The management of the descriptive texts supports adding images. In case an image is added, it will initially be added as 'bytes' to the description and in the background the image is save to the image server. Once save the 'bytes' are then replaced with the location of the image.
When adding very large images (several Mb's) the timing of saving the image and replacing the 'bytes' with the URL can not be finished prior to the user Save action. This means that the description of several Mb's will be saved, which is limited. This is the technical background to provide some details on what happened.
Several changes are applied to create a more robust (error proof) handling of descriptions with images. The save shouldn't give a 'system error', but a useful message for the user. For instance, the text is saved, but the image could not be uploaded. This means the user has the text and can add the image again, or maybe reduce the image size to a size more suitable for web viewing and then add it. Several 'error' situations were identified and have been solved based on the above tactic.
As a department manager I want to approve ad-hoc absence requests - CUR-2034
(Un)availability management of staff members is standard supported in different means. The until this release supported (un)availability was based on generic setting steered with the weekly availability pattern or a number or percentage of unavailability hours in the context of workload.
The image below shows the user screen to define the weekly availability pattern.
In this release the option is added to support the request of 'ad-hoc' unavailability by a user and the approval by the HR manager.
A new screen is introduced called 'unavailability', that can be added to the user Tab settings as shown in the image below, but can also be added into a workflow to gather 'ad-hoc' unavailability prior to the semester start.
The user is shown an overview of the ad-hoc requests done and their status. The user can define additional ad-hoc unavailabilities by clicking the Add button.
The user can specify:
- Start and end date
- Start and end time
- Type, allowing to define if it should be set als unavailable, available or rather not
- Description to define the reason for the absence
The HR manager will have access to the Absence report (unavailability-report) that will show an overview of the the staff unavailability request.
The image below shows the standard view. The HR manager can filter on date to select only request that have been filed between specific dates, or on status to only see the 'open' requests (or the approved / rejected ones).
The HR manager can use the toggle buttons to 'select all' or 'select one/more' requests from the list. In the image below the HR manager selected one request. Once selected the Approve and Reject button appear to enable the HR manager to manage the request.
In case the HR manager approves the request, a pop-up appears that allows the further handling of the request. The HR manager can decide to just accept and without providing any additional information and handling, but can also decide the absence should both have effect on the availability in scheduling and in the availability of the person in relation to workload.
In the image below the latter is chosen. The HR manager has marked that for this request a 'task' should be created that will have effect on the total availability of the person. The request should be marked and saved as an ad-hoc absence task in the users profile. The amount of hours is calculated based on the request, but can be adjusted at this moment.
If we then look at the users profile, we notice a task has been added in the section 'Absence'. The task size is 16 hours and this 16 hours will be deducted from the total available hours for the person.
This means that an unavailability 'marked' as task will lead to an additional deduction of hours, next to the standard user availability hours that already has deducted the contract defined leave hours.
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.
Extend Broker with support for OOAPI v5 - CUR-2202
The data is managed and stored in Curriculum, optimised to support the management of data. With the increase of 'retrieval' oriented interface we noticed that this optimisation is not the most effective way for mass retrieval. In order to support mass retrieval the Broker is introduced a few months ago, that is 100% designed to support mass retrieval of Curriculum managed information.
From a technical perspective the Broker will receive 'approved' data from Curriculum and save the information in the read-optimised format. The Broker can be accessed using the API to retrieve studies, modules. Where the Curriculum API has to 'gather all data and generate the JSON output message', the Broker has direct acces to the JSON output message, since that is the optimised storage format.
This release the Broker is extended with OOAPI services. Due to the nature of one of the services using OOAPI that every 5 minutes does a full refresh of all studies / modules, the generated peak load affected the Curriculum performance. In some cases the load was so high and the generation of the response was not fast enough (exceeding 60 seconds) that the 'requesting' system showed an empty result. Initial test with the same requests and data to compare Curriculum versus Broker API calls learns that the read optimised Broker is between 20 and 100 times faster.
The initial set of OOAPI services implemented in the Broker, to support eduXchange data retrieval, is:
- Organization
- Specification
- Programs
- Courses
- Offerings
The service definition is available in Swagger format at https://curriculum-broker.eu.timeedit.net/v3/api-docs
getGroup service should return the module-group -> module attributes - CUR-2239
The getGroup service didn't return the user defined custom-fields on the module-group to module relationship. Only the standard available (and pre-configured) Curriculum fields were returned. This has been changed and the getGroup service will now return all defined custom-fields on the module-group to module relation.
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.
This release no vulnerabilities has been reported that require mitigation.
Refer to the Curriculum manual for configuration guidance.