Curriculum: Versioning configuration and usage

When using versioning, the academic year as a logical concept is still used. This means a user can still look at the study or module in a specific academic year. Changes are not made in the context of that year, but are made to the version shown. This means that when changing a study structure (version spanning multiple year) in its third year of existence, the earlier logical years are changed too. Since the version spanning multiple years is changed.

The image below shows the versioning concept.

• In the top part there are two consecutive versions of the same program, where version 1 (v1) has an end date in 2027, and version 2 (v2) starts in 2028.
• In the bottom part there are three versions of the same module. The version 1 (v1) and version 2 (v2) can be considered as consecutive versions of the same module. The version 3 (v3) is a parallel version of the module next to version 1 and version 2.

The concept of parallel and consecutive is equal for study, module-group and module. Multiple parallel and consecutive study and module-group versions can be defined, similar to the module shown in the image.

The image above shows both a Program and Module that spans all years. This is the object that is used as the container for the underlying version.

The configuration of versioning requires a number of steps:

1. Enable versioning
2. Migrate existing data to support versioning
3. Change the custom-field configuration to support creation of new versions
4. Change the relevant forms to support start and end date definition

Before starting, it’s good to be aware there is no way back once versioning is enabled and the data is migrated.

‍

Enable versioning

To enable versioning, navigate to the Administration -> Configuration page.

• Search for the configuration option versioning.enabled
• Set the value for versioning.enabled from the default value (false) to true

The system will use the versioning mechanism for all new data created.

‍

Migrate existing data to support versioning

If the system already has data, prior to changing and/or creating new educational objects, first the existing data must be migrated to support versioning.

The migration script does have logic and will create ‘definition objects’ and underlying version with their respective start and end dates based on the academic year(s) they’re bound to.

To start the data migration, navigate to the Administration -> Scripts page.

• Click on the Add button
• Select the script Migrate to versioning and click Execute

• The migration can take some time (5-10 minutes), wait with any further actions till the migration is finished.
• Select the script Optimize database and click Execute

Once the database optimization has finished, the system is technically migrated to versioning support.

‍

Change the custom-field configuration to support creation of new versions

Since new versions will be based on an existing version, the selection of an existing version should be supported. On the study, module-group and the module the originalId must be enabled and the academicYearId should be disabled. The image shows the configuration for the module, the setup for module-group and study is equal.

Change the relevant forms to support versioning, start and end date definition

The explanation for forms (pages) to change will be done using the module as an example. The same changes should be applied to study and module-group.

The custom-field definition of a module can be used to create a default Create form. If the create form is not configured, create a new page and add it to the create page configuration for the module.

The create page is a form page, that should contain the relevant fields for the creation of a new module. The screenshot below shows a configuration to create a new module using versioning. The main addition is the originalId, which is in the screen represented as the option to select a module version that will be the foundation for the new version. In other words, the selected module version will be copied and saved as a new version.

The code is the unique version code, and should contain a formula that will automatically generate the new version. More information and examples will be added. For now (during testing) the code should filled manually.

The name will be copied from the original version (the one that is copied), and can be kept the same, or can be adjusted.

The start and end date can be used to define the life-cycle of the module. The end date may not be necessary, the start date is, since it can be used to define the start date of the new created version.

The users of the system can use the versioning. The most prominent or clear location is on the structure page. Once versioning is configured, next to the year switcher a version switcher is shown. This is valid for the study, module-group and module data.

The example shows a study with the version switcher. Clicking the version switcher will show the different defined versions for the AD Academic operations. Depending on the selected year and the start and end date of the individual versions, the active / available versions in that year are shown.

To create a new version, navigate to the module-group that should contain a new version. Select the +-icon and select the option Add module (or Add module-group if that is configured).

The default Add module option is shown, with support to add an existing or a new module. In case versioning is enabled, a new tab-option is added to create a new version of an existing module.

The fields shown are the ones defined earlier in the New module form. The originalId (Copy of) can be used to select the module version that is the foundation for this version.

‍