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.

‍

HTML ordered list is different visualised in history, edit and preview mode- CUR-1667

The ordered list in the HTML preview was not showing equal to the edit mode. This has been fixed, to get a similar experience in the edit and preview mode.

‍

Extended option for workload management calculation rules - CUR-1682

The workload management calculation rules is extended with a new standard field :activity_amount that can be used in the calculations.

This field is providing the number of activities defined, to allow calculations based on the number, e.g. to get the nett hours and 1.5 hour preparation time for each activity -> :activity_hours + (1.5 * :activity_ amount)

‍

Tasks should not be available for persons having an inactive relation with an educational object - CUR-1674

When and if tasks on the Dashboard are displayed to the assigned user was not always consistent or clear. Tasks could be displayed to related stakeholders that had no active relation with the object any more. This has been altered to provide a clear and standard visualisation where tasks and their workflow are only displayed and accessible if the user has an active relation.

‍

As an admin I want to go crazy on conditions - CUR-1731

Conditions can be used to steer the behaviour in Curriculum based on fields, rights and other information, e.g. only show a field or page if another field is set to a specific value.
The condition was maximised at a length of 512 characters. This seems to not enough, so the limit is extended to 1024 characters.

‍

Usability improvement using self-configured reports including filtering - CUR-1705

The functionality to create your own report templates supports selecting any defined custom-field to be shown, but also to be used as a filter. From a technical perspective not all added custom-fields are indexed (optimised for filtering). This allows definition of reports for thousands of modules with a filter on a non-optimised field.

Nothing has been changed to the above option, and thus still allowing the user to define any report and filter on any of the fields. Using non-optimised fields for filtering can lead to longer loading times showing the filtered report. An information message is shown to the user when saving or executing a report with a filter on a non-optimised field. This so the user knows retrieving this report will take longer.

As a best practice it is advised to have your default report (with the lowest sequence number) without filtering options. This will direct show the data, and only navigate to the 'non-optimised filtered report' once needed.

‍

The dashboard loading time should be improved (having > 1000 tasks on my Dashboard) - CUR-1775

The dashboard was designed to provide an overview of the outstanding tasks of the user. It was not really anticipated having over a 1000 tasks would happen.

A slight change has been made retrieving the tasks:

• Only 50 tasks are retrieved when building up the dashboard
• In case there are more than 50 tasks, a 'show more' button is shown to allow the user to retrieve all

Simultaneously a performance change is made retrieving huge number of tasks from the general page by adding more strict filtering reducing the sample with > 1000 task from 20 seconds to 50 milliseconds.

‍

Improve the visualisation of the read-only form pages - CUR-1791

Form pages used as 'read-only' in workflows or in reports were just made read-only while still showing the 'select / input' type, e.g., a Boolean value showed the slider Yes|No or a toggle.

This has been cleaned-up where all 'make-up' of the the input information shown has been removed and the input information is showing just the selected value as plain text. So the Boolean is showing either the text Yes or No and no longer the 'read-only slider'.

The information if a value is considered required and in-line tooltips are still shown to still offer the background information when using the information online.

While configuring I want to see where a custom-field is used - CUR-31

The visualisation of the custom-field definition has been enriched showing the pages a custom-field is used. This to support the admin configuring the system to validate if a field is shown to users and on what pages.

The pages shown are 'clickable' and will open the actual page configuration of that page.

‍

Extend support for activity-series using custom pages and workflows - CUR-1768

The so-called root objects (Module, Method, Assessment, Study, ...) support usage of custom pages and workflow to create or edit the information shown. This was not yet supported for activity-series, since it's a child of the Method or Assessment root type. Support to use the same functionality has been added to the activity-serie object type.

‍

Usability improvement 'shown full name' for tasks on the dashboard - CUR-1774

The tasks shown in the dashboard were truncated in case they exceeded the maximum 'visualisation' space available. In case codes and the start of object naming are more or less similar, all tasks look the same. A option is added using mouse-over to visualise the full name of the object.

‍

A date field shown in the curriculum tree should be shown as date - CUR-1758

The curriculum tree provides support for adding additional columns to be shown. In case a custom-field of type Date is added, this is displayed as a timestamp (YYYYMMDDTHH:MM:SS.mmm).
This has been fixed so a date field is properly shown adhering to the configured visualisation format. e.g. YYYY-MM-DD.

‍

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 integration related issues have been reported or solved.

‍

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 no vulnerabilities were reported, so a quit sprint on that area

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.