The Administration -> Custom fields menu offers two functions:

• Configure the behaviour of pre-defined Curriculum fields and objects
• Extend the basic definition by adding new fields and/or objects

Selecting the menu will provide an overview of all available main objects (e.g. Academic year, Assessment, Assignment, ..., Study, Qualification) and for each object the available sub-objects.

Open the object type to be managed.
The example shows the configuration options for the Module object.

There are three options marked red:

• Module (module) - right top-hand corner. Allows to quickly switch between the different sub-objects in Module.
• General - the option to define the basic object behaviour
• Custom fields - the option to change pre-defined field configurations or extend Curriculum with new fields (next section).

The basic object configuration supports a number of configuration options:

• Label - The name that will be used showing the module, instead of the system defined label.
• Sequence - The order in which the object is shown in the list
• Comments - Define the generic behaviour for changes to fields defined on the Module (module) object/sub-object. This will be the default behaviour that can be overwritten in the individual Page configurations
• Message within change - Configurable message to show within changes made on objects of this type. This message will overwrite the standard Curriculum message. The following variables are supported:
  • {{createdBy}}
  • {{changeType}}
  • {{changeTypeLowerCase}}
  • {{changedEntity}}
  • {{rootEntity}}
• Create possible - Defines if and when changes to the Module are allowed:
  • Always - create is always allowed, based on authorisation
  • Never - create is never allowed (not even for admins)
  • Simulation - create is always allowed in a simulation
• Action after create - Defines what action is executed after the creation of a new object:
  • Open in new tab - The create will open an new tab with the Create page allowing to enter the requested information
  • Open popup - The create will open a popup with the Create page allowing to enter the requested information
  • Start process - The create will start a process, the task will be available at the Dashboard of the assigned stakeholder
  • Start process in popup - The create will start a process that opens in a popup. Simultaneous a task will be made available at the users dashboard, so closing the popup will still allow to finish the creation process at a later stage from the dashboard task.
• Delete possible - Defines if it is allowed to delete modules by admins
• Visible during search - Is the object (module in this example) search using the quick-search
• Generate code - Will the code (main object identifier) be generated by Curriculum using a formula defined at the Code field.
• Filter on types - Filter on module type (code), to only enable module for specific module types
• Process - Configure the process that should be used at create (Action after create = process)
• Edit workflow - Configure the workflow to be used on Edit of the object. E.g. the edit of a module in the study structure tree.
• Preview page - Configure the page to be used when previewing the object. E.g. a read-only rows page providing the report.
• Create page - Configure the page used at create (Action after create = popup / tab)
• Minimum - Minimum number of objects required in a parent object. This is more relevant for the assessment and method schemes where you can set that at least 1 methods is required.
• Maximum - Minimum number of objects allowed in a parent object.

Extending Curriculum with new fields will use the custom fields tab, marked red in the picture above.

Most of the new fields added will be added to the additional sub-object.
The example below shows the fields that for this specific implementation are added to the standard Curriculum fields.

Fields can be added / manipulated on each of the sub-objects. The ones used the most frequent are:

• Additional - The standard location to add fields. Always select this, unless the reason to use one of the next mentioned sub-objects is valid.
• Root - The root object is the object that has the same name as the selected object, e.g. Module (module), Study (study).
  The root object is only used for fields that should only be accessible to the admin or require authorisation based on admin-rights
• Credits / Capacity - Standard 3 fields are defined for Credits and Capacity. In case not all three are needed, or additional credit/capacity related fields are required they can be added to the Credits/Capacity sub-object.
• Offering - Offering related fields (fields that are defined on the module -> offering relationship) should be defined at the offering sub-object.
  A simple example is the field Period. This field is defined at the relationship of an individual module with an offering period in context. Allowing module A in module-group A to be provided in Period 1, and module A in module-group B in Period 4.

The other sub-objects are behaving like the offering, meaning that the fields defined are the fields relevant at the relationship and in context.
‍

To Add or manage a custom-field, click on the Add button or the custom-field.
An extensive amount of configuration options is supported as is shown in the example below (that is cut in two pieces).

Configuration option supported are:

• Name - The unique code of the field, used to identify the field in the API
• Label - The name shown to users for the field
• Type - The field type, supported options are:
  • Boolean - Boolean (true / false)
  • Date - Date picker
  • Datetime - Date-time picker
  • Element - Select from a configured Element and its values
  • Entity - Select an object from the system, e.g. a person)
  • Number - A numeric value
  • Reference- Select from a configured Reference and its values
  • String - A text field, use display options to show text-field or text-area
  • UUID - UUID value
• Subtype - Used for Element, Entity and Reference to define the related select list or object type.
• Filter - Restrict the options values (Element, Entity) based on a filter
• Required - Define if the field is required
• Default value - Set the default value, only valid in case the field is required.
  For Element or Reference mark the option to be the default value as default selected.
  
• Visible - Show the field. This can be used to hide fields that are no longer relevant.
• Sequence - The order in which the fields are shown. This applies to the standard additional page template. Most cases a more targeted Forms template is used, where the order is defined at the page itself.
• Value display - Defines how the selected type will be shown. Supported values are:
  • Autocomplete (Element and Reference-only)
  • Dropdown (Element and Reference-only)
  • Dropdown filter (Element and Reference-only)
  • Dropdown select (Element and Reference-only)
  • Email address (String-only)
  • Hidden (String-only) - specific option to enable using a formula on a field, that is available on the page but hidden.
    Rationale: the calculation of the formula is executed in the front-end, and the field to be calculated must be available on the page.
  • Horizontal button group (Element and Reference-only)
  • Horizontal checkboxes (Element and Reference-only)
  • HTML text (String-only)
  • Markdown text (String-only)
  • Password (String-only)
  • Reference selector (Element and Reference-only)
  • Select (Element and Reference only)
  • Text-area (String-only)
  • Vertical checkboxes (Element and Reference-only)
• Edit in report - Configure the field is editable in reports, to enable bulk change from a report.
• Hide in history - Define changes to this field are not shown in the history
• Condition - Define the condition to show/hide the field based on an expression (:typeId in ('BA', 'MA')
• Formula - Define the formula used to generate the value for this field
• When to generate - Define when the field value should be generated based on the formula:
  • Always - The value will be regenerated always
  • On create - The value will only be generated at create
  • Only when empty - The value will only be generated if the current value is empty
• Unique value - Define if the generated valued should be unique and should be tested against all values in the system.
• Allowed to create - Is it allowed to define a value for this field by a user
• Read only - Define the field is read-only (and thus for information purposes)

The configuration continuous with the second half of the configuration of our new field SkillModuleReq:

• Editable - Define in what status the field is editable, taking authorisation rules in consideration:
  • Always - The field is always editable.
  • Existing - The field is only editable if it already exists (has a value)
  • New - The field is only editable if it doesn't exist yet (has no value)
  • Published - The field is only editable if the object has been published
  • Unpublished - The field is only editable if the object has NOT been published
• Operation - The security operation that should be used to restrict access to the object.
• Number of decimals - The number of decimals the user can/may enter. Only applicable for Number type
• Min. value - The minimum value entered, only applicable for Number type
• Max. value - The maximum value entered, only applicable for Number type
• Maximum number of characters - Define the maximum length of a String type
• Regenerate code - Indicator if an existing code should be regenerated
• Multiple values - Indicator if the field is considered a multi-value field
• Ignore in year copy - Define if the data for this field should NOT be copied over in the year roll-over
• Display on general - Indicator if the custom field is shown on the general Tab of the object.
• Display code and name - Display both the code and name in report pages, instead of only the name
• Filter field - Indicator if this field can be used as filter in reports
• Section - Assign the field to a section
• Tooltip display type - Indicator if and how tooltips for the custom field must be shown.
  • On mouse-over (the custom field will have an (i), that will show a pop-up with the tooltip on mouse-over)
  • Small text beneath label (the tooltip is always shown on the screen, underneath the label)
    
• Tooltip text - The text to be shown as tooltip.
• Export inverse as - Define the code that is used to export an inverse reference list selection.
  In case the question is 'select 3 things you don't want out of the 60 options', the result would be the selection of 3. But the requirement of an interface would be to get the 57 wanted options. The user is made life easy by asking a 'NOT', and by setting this field value both the selected values using the original code AND the unselected values using this code will be available via the API.
• Start date - The date the field will become available
• End date - The date the field will no longer be available (in future).

‍

Extending Curriculum with new objects will use the custom fields tab, marked red in the picture above. In Curriculum a self-defined object is a simple (un-nested) object that acts like a recordset with its own fields.

Definition of a new or managing an existing self-defined object is done either using the Add-button, or by clicking on the object.

The self-defined objects can be identified by looking at the type. In case of a self-defined object the type = item.

Click on Add to create a new object.

All configuration options available for general object behaviour can be used, but in 99.9% of cased only the fields shown in the example are necessary.

The object will be created, and the next step is to edit the object by adding the fields to be available for the object.
This is exactly the same as adding / managing fields on any of the other objects covered in the previous section.