Curriculum has a pre-defined set of objects that are used to model and define and maintain the institute organisation, curriculum and workload processes.

Curriculum uses for its foundation a so-called bespoke model that standard supports the institute structure from the faculties down to individual activities at module level. The term frequently used for these bespoke object is the 'root object'. The root object is one of the foundation elements (objects) in the top-down structure and will consist itself of standard objects and fields. The standard available objects and fields support the base process and base structure requirements of any institute. Next to the standard objects the system can easily be extended with custom objects and fields. This is explained in the next section.

The extensibility has always been the main design principle for curriculum, right from the beginning. This is based on the fact that all users have different requirements, structures and external systems to be integrated and fed with specific information. The root objects and their standard child-objects can be considered the common denominator to cover all standard requirements and extend from their using the customer added fields and objects.

The overview of the root objects is shown below. The name shown behind brackets is the internal used name and can also be used in configuring calculated fields and expressions. The name before the brackets is the standard naming at first install, but might be different for each installation due to changing these names use the Label edit function to the internal used naming convention.

The overview is not shown in alphabetical order, but in a hierarchy based order (top -> down), and ended with the more generic objects that contribute to the structure.

Faculty (faculty)

Object to model the Faculty information of the institute, e.g. Faculty of Law, Faculty of Science

• Faculty (faculty)
  The faculty root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element.
• Method parameter (method-parameter)
  The method-parameter object is an internal (technical) object used for Workload Management. It will contain the different workload calculation rules for the individual teaching and assessment methods.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).

Organisation (organisation)

Object to model the HR organisations of the institute, e.g. Department of business Law

• Organisation (organisation)
  The organisation root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).

Specification (specification)

Object to model the accredited programs, e.g. Bachelor of Law, Master of Science

• Specification (specification)
  The specification root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Capacity (capacity)
  The capacity object used to define the number of students and standard providing minimum, optimum and maximum capacity.
• Credits (credits)The credits object used to define the number of credits and standard providing minimum, optimum and maximum capacity. Don't rename the field names, only labels, since these three fields are used in the curriculum structure to identify if the amount of required minimum, optimum (standard) and/or maximum is met in the underlying module-groups and modules.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element.
• Document (document)
  The document object will hold the uploaded documents and their related information like type, date, etc.
• Subject/Learning outcome (subject)
  The subject object will hold the learning outcomes the student can obtain with the specification. At study level, the actual learning outcomes for the 'offered program' are derived from this set and configured.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).

Qualification (qualification)

Object to model the obtainable qualification, e.g. Bachelor of Law, Certificate of Arts and Science

• Qualification (qualification)
  The qualification root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element.
• Link (link)
  The link object is used to manage the link(s), e.g. required, excludes between the qualification, specification and study objects.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).

Study (study)

Object to module the offered program, e.g. Bachelor of Law (full-time), Bachelor of Business Law (part-time), Master of Arts (Rotterdam)

• Study (study)
  The study root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Advice
  The advice object is an internal object used to manage the different advices given to proposed changes in the curriculum structure
• Award qualification (award-qualification)
  The award-qualification object is used to relate the study and its obtainable qualifications.
• Capacity (capacity)
  The capacity object used to define the number of students and standard providing minimum, optimum and maximum capacity.
• Credits (credits)The credits object used to define the number of credits and standard providing minimum, optimum and maximum capacity. Don't rename the field names, only labels, since these three fields are used in the curriculum structure to identify if the amount of required minimum, optimum (standard) and/or maximum is met in the underlying module-groups and modules.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element
• Document (document)
  The document object will hold the uploaded documents and their related information like type, date, etc.
• Effort (effort)
  The effort object will hold the calculated Workload management effort that is required to deliver the object
• Subject/Learning outcome (subject)
  The subject object will hold the learning outcomes the student can obtain with the specification. At study level, the actual learning outcomes for the 'offered program' are derived from this set and configured
• Link
  The link object is used to manage the link(s), e.g. required, excludes between the study and other educational objects in the system.
• Offering period (offering-period)
  The offering-period object defines the start moments the program is offered, e.g. September start, February start.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).
• Route (route)
  The route object is used to hold the different routes and related qualifications a student can follow within the program. E.g. all modules in year 1 will provide a Certificate or February start should start with these X modules in semester 2
• Structure (study-module-group)
  The study-module-group object is the foundation for the curriculum tree direct from the study downwards. It will hold the module-groups directly related to the study, including its relation related fields such as phase or required information.

Module group (module-group)

Object to model the clusters of modules that are part of offered programs. E.g., Year 1, Propedeuse, Specialisation Civil Law

• Module group (module-group)
  The module-group root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Capacity (capacity)
  The capacity object used to define the number of students and standard providing minimum, optimum and maximum capacity.
• Credits (credits)
  The credits object used to define the number of credits and standard providing minimum, optimum and maximum capacity. Don't rename the field names, only labels, since these three fields are used in the curriculum structure to identify if the amount of required minimum, optimum (standard) and/or maximum is met in the underlying module-groups and modules.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element
• Document (document)
  The document object will hold the uploaded documents and their related information like type, date, etc.
• Effort (effort)
  The effort object will hold the calculated Workload management effort that is required to deliver the object
• Subject/Learning outcome (subject)
  The subject object will hold the learning outcomes the student can obtain with the specification. At study level, the actual learning outcomes for the 'offered program' are derived from this set and configured.
• Link
  The link object is used to manage the link(s), e.g. required, excludes between the module-group and other educational objects in the system.
• Offering period (offering-period)
  The offering-period object defines the start moments the program is offered, e.g. September start, February start.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).
• Structure (module-group-module-group)
  The module-group-module-group object is the foundation for the curriculum tree direct from the module-group downwards. It will hold the module-groups directly related to the module-group, including its relation related fields such as sequence or required information.
• Structure (module-group-module)
  The module-group-module object is the foundation for the curriculum tree direct from the module-group downwards. It will hold the modules directly related to the study, including its relation related fields such as sequence or required information.

Module (module)

Object to model the modules that are part of offered programs. E.g. Introduction to Law, Basic analytics.

• Module  (module)
  The module root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, abbreviation, start and end date, etc.
• Additional (additional)
  The additional object is the standard object used to extend the data model with self-defined custom-fields.
• Appraisal
  The appraisal object is an internal object that is used to model the assessment tree and enable use of assessment in different modules. E.g. a test is used in module A and module B, and in module A its weighting is 50% and in module B its weighting is 20%.
• Capacity (capacity)
  The capacity object is used to define the number of students and standard providing minimum, optimum and maximum capacity.
• Delivery
  The delivery object is used to manage the delivery plan for assets, e.g. deliver 23 times book A in week 4 from stock.
• Credits (credits)
  The credits object used to define the number of credits and standard providing minimum, optimum and maximum capacity. Don't rename the field names, only labels, since these three fields are used in the curriculum structure to identify if the amount of required minimum, optimum (standard) and/or maximum is met in the underlying module-groups and modules.
• Description (description)
  The description object is an internal (technical) object that is used to manage and maintain the multi-lingual descriptive texts. The supported descriptive texts are configured using the Element
• Division
  The division object is used in Workload management to maintain the hour/cost division of a module against the organisation structure.
• Document (document)
  The document object will hold the uploaded documents and their related information like type, date, etc.
• Education week (module-week)
  The module-week is an internal object to hold the activity required sequence information, e.g. in week 4 the order of activities should be lecture A, workgroup C, workgroup B
• Effort (effort)
  The effort object will hold the calculated Workload management effort that is required to deliver the object
• Subject/Learning outcome (subject)
  The subject object will hold the learning outcomes the student will learn with the module. At module level, the actual learning outcomes are derived from the 'offered program' and configured.
• Link
  The link object is used to manage the link(s), e.g. required, excludes between the module and other educational objects in the system.
• Material (asset)
  The material object is used to manage the required material/resources to deliver the module
• Method schema (method-schema)
  The method-scheme object is an internal object that is used to model the method tree and enable use of assessment in different modules. E.g. a test is used in module A and module B, and in module A its required and in module B its optional.
• Offering period (offering-period)
  The offering-period object defines the start moments the program is offered, e.g. September start, February start.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).
• Resource (module-resource)
  The module-resource object is an internal object used to relate module resource information to specific offering periods.

Assessment (assessment)

Object to module the assessment and its delivery, e.g. Oral, Digital, Portfolio

• A
  The assessment root that will hold the standard (identifying) curriculum assessment fields like code, external Id, multi-lingual names, abbreviation, duration, minimal grade, type, etc.
• Activity (activity)
  The activity object is used to hold the lecturers (persons) that are related to the individual assessment activities
• Activity planning (activity-planning)
  The activity-planning object is used to hold the weeks the assessments are planned during the offering period
• Activity serie (activity-serie)
  The activity-serie object is used to hold the activity series (sets of activities and activity-planning) defined for a module, e.g. cumulative test serie in week 1, 4, and 8 and a final test in week 10
• Appraisal (appraisal)
  The appraisal object is an internal object that is used to model the assessment tree and enable use of assessment in different modules. E.g. a test is used in module A and module B, and in module A its weighting is 50% and in module B its weighting is 20%.
• Subject/Learning outcome (subject)
  The subject object will hold the learning outcomes the student will be tested in the assessment.

Teaching method (method)

Object to module the assessment and its delivery, e.g. Oral, Digital, Portfolio

• Teaching method (method)
  The teaching method root that will hold the standard (identifying) curriculum teaching method fields like code, external Id, multi-lingual names, abbreviation, duration, nr. of groups, type, etc.
• Activity (activity)
  The activity object is used to hold the lecturers (persons) that are related to the individual assessment activities
• Activity planning (activity-planning)
  The activity-planning object is used to hold the weeks the assessments are planned during the offering period
• Activity serie (activity-serie)
  The activity-serie object is used to hold the activity series (sets of activities and activity-planning) defined for a module, e.g. cumulative test serie in week 1, 4, and 8 and a final test in week 10
• Subject/Learning outcome (subject)
  The subject object will hold the learning outcomes the student will be tested in the assessment.
• Method schema (method-scheme)
  The method-scheme object is an internal object that is used to model the method tree and enable use of assessment in different modules. E.g. a test is used in module A and module B, and in module A its required and in module B its optional.

The above mentioned objects are used to structure and manage the core curriculum. The next objects can be considered as more generic objects that contribute to many objects are are used to steer processes.

Academic year (academic_year)

Object to module the academic year, used to version the year and its related processes and data

• Academic year (academic-year)
  The academic-year object is a fully internal object that is used to hold the academic years and its calendar information.
• Relation/person (relation)
  The relation object is used to hold the relation with the assigned persons with the configured relation-types for the root object.  Additional fields to specify or add to the relation can be configured, or standard fields can be made invisible to limit specific functionality (e.g. usage of 'virtual / vacancy' persons).

Learning objective (objective)

Object to model the learning objectives the student will get taught/learn in a module. E.g. create a pivot table in Excel, write a paper in academic English.

• Learning objective (objective)
  The objective root that will hold the standard (identifying) curriculum fields like code, external Id, multi-lingual names, description.
• Appraisal
  The appraisal object is an internal object and is used to relate the learning objective to the assessment it will be assessed with. This relationship supports the assessment plan including the assessments and the related objectives tested in the different assessments.
• Subject/Learning outcome (subject)
  The subject object is an internal object and is used to relate the learning objective to the subject it contributes to. This relationship is used in the different matrix reports in Curriculum Mapping.

Resource (resource)

Object to model the resources in the system. Resources are managed using the resource management functionality and are used in module context.

• Resource (resource)
  The resource object is an internal object used to define and manage resources to be used in the context of other objects (e.g. module).
• Resource version (resource-version)
  The resource version object is an internal object that support management of resource versions

Rule (rule)

Object to model rules in the system. Rules are used to define relations between objects, including the applied rule, e.g. a qualification can be obtained via (Module A and B) or(Module A and Module-group C)

• Rule (rule)
  The rule object is an internal object used to define and manage rules to be used in the context of other objects (e.g. module), e.g. requires, excludes.
• Link
  The link object is used to manage the rule's relations with the educational objects, e.g. Module E requires module A

Person (person)

Object to model the users / persons in the system. The person object is at the heart of the system and is used for authorisation, process management, stakeholder definition, responsibilities, etc.
In a workload management context the relation is using the assignment that can be considered a wrapper around person.

• Person (person)
  The person object represents the actual person (user / login) that will have access to the system and can be used to define relationships with the other objects.
• Availability preference (availability-preference)
  The availability-preference object is an internal object that holds the weekly availability pattern per offering period of the user
• Availability request (availability-request)
  The availability-request object is an internal object that is used in Workload management context to hold and manage the ad-hoc (un)availability requests of the user, including approval status.

Assignment (assignment)

Object to model the person assignment, e.g. 50% FTE for the Department of Erasmus studies.
In a Workload management context the relationships from objects (study, module-group, module, ...) are against the assignment where workload calculations are required. The authentication and authorisation layer will use the person bound to the assignment.

• Assignment (assignment)
  The assignment object will hold the assignment, in the above example it is the assignment with the Department of Erasmus studies.
• FTE (fte)
  The fte object will hold the FTE percentage per year for the different assignments, in the above example this is 50%.
• Task (task)
  The task object will hold the assigned non-educational task to the person, including the allocation value. E.g., paper reader for 5 students, 35% module coordinator for Module A
  ‍

Team (team)

Object to model and manage teams of persons, e.g. Exam Committee has team members John and Jane Doe.

• Team (team)
  The team object is used to define and manage teams and its team members (persons)

Next to Person and Assignment, a Team can be used in relationship configuration. This means a study director can be:

• a Person (John Doe)
• an Assignment (John Doe's contract of 50% with Department of Science)
• a Team (John and JaneDoe)

The Administration -> Custom fields menu offers two functions:

• Configure the behaviour of pre-defined Curriculum root objects and their child objects and fields
• 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.
• Searchable - Indicates if the field is available for the advanced Person search, e.g. enable the field teacherQualification for searching person with a specific qualification
• 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 - Field is editable in the standard reports using the bulk change option
• 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.
  The generation of the unique code is covered by the back-end to be 100% sure all values are included in the generation of the unique code. Different options are available to determine if and when uniqueness is determined:
  
  • Always: will regenerate the code in the UI each time the object is saved, so might not be unique system wide
  • On empty: will regenerate the code in the UI, so might not be unique system wide
  • On save: will  regenerate the code each time the object is saved in the backend, guaranteeing a unique codeOn save empty: will only generate the unique code once (when the object is created new) in the backend, guaranteeing a unique code
  • On create: will only generate the unique code once (when the object is created new)Configuration:Based on the exact requirement on guaranteed uniqueness, it is advised to alter the current settings 'always' and 'on empty' to the 'on save' and 'on save empty' behaviour.
• Block duplicates - Configures the behaviour of the 'unique value check'. In case block values is set, an error is thrown and the user cannot save. In case the block values is not set, a warning is thrown and the user can save the object with the same value.
• 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)
• Pattern - Defines the pattern to be displayed. E.g., for Period display the pattern can be configured using the offering fields, e.g. a combination of the period and a location.‍
  
  • :join(:name, ' (', :(offering) location, ')') -> Semester 1 (Rotterdam)

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.

‍

‍