User management is available via the menu Administration -> People  and is used to manage the users who should have access to the system.

In a standard setup the Users are provisioned using the standard Curriculum API.
In case users are not yet provisioned they can be imported by CSV or defined and maintained manually.

The user management will show a list of all defined users.

Using the quick search, the switch between active, inactive and all or the specific filter options, the list can be adjusted.

Supported filter criteria are:

• Role - system role the user has (User, Client, Administrator, System administrator)
• Related as - the user has the selected relation type with any educational object
• Has external ID - the user has a defined external ID
• Ignore - the users is marked as ignore, which is used to not show the user in user lists in Curriculum to standard users
• Password filled - the password field is set, which allows the user to login on test/acceptance via the internal login

Users can be created (New button) or modified (Edit button). Click on the record to view the User details.
The ->[Login] button allows the administrator to 'login as ...' the selected user.
Users are not deleted, instead a 'soft delete' is executed by setting the end date to keep correct historic data and audit trails.

The User definition consists of the following attributes

• External Id - Unique institution SSO login for the user, used both for login by the user and exchanging information (provisioning and defining relations in academic structure)
• Code - Additional option to store a unique identifier for the user that can be used in exchanging information
• Personal nr. - Optional field that can be used to store specific personnel related data (personnel number)
• Full name - Full (display) name of the user (required)
• First name - First name of the user (optional)
• Last name prefix - Last name prefix (optional)
• Last name - Last name of the user (optional)
• Email - The email address of the user, used for sending notifications
• Photo URL - URL to an image file, to allow for displaying an avatar for the user
• Ignore - Indicator if this user is ignored in allocating users to a role in the curriculum. Used to 'exclude' administrators in user search.
• Simulation - Indicator if the user is allowed to use the Simulation option. Simulation can be defined on User group level and on individual users.
• Role - The system role for this user that defines the global role and rights. The detailed (context related) rights are defined by relations of persons to the various objects, e.g. study manager, module coordinator.
  The system roles are:
  - Administrator: Administrative rights
  - API: Specific role for API access
  - User: Default role, used for all users except administrators.
  - System administrator: Administrative rights, with some additional functions on technical configuration level. Mainly used by TimeEdit support staff.
• Password - Optional password. In case the system is using the institution SSO, the password will not be used.
  In case the system uses the Curriculum as the User and Authentication store the password is required and will be used to authenticate login.
• Start date - Contract start datum
• End date - Contract enddate
  The screenshot with the user list shows a user with an end date that is passed marked in red with strike-through. The user is still available in historic years prior to the end date, but will no longer have access or be available for selection as lecturer (or another role) after the end date has passed.

Just like other objects in Curriculum, there is the option to extend the User definition by adding custom-fields to the Additional sub-object. This option is in general explained in the guide on extending Curriculum.

The extension of the User object can be used to add user specific information that can be used to report on. For instance the education qualification(s) a user has, or areas of expertise, internal / external staff member, etc.

There is a strict separation of the management of users and configuration of the additional fields (admin task) and the entering of data and reporting on the user added fields. From the administrator menu the admin cannot fill the additional fields, since they are / should be owned by the business.

Of course the admin can be of help by using CSV to import values for the different person added fields.

The users will have access (based on authorisation) to the person report showing all persons in their context (e.g. system, faculty) and are able to report and manage the information shown from the report. Next to the added fields, there is a limited set of the standard user-information available in the report, e.g. externalId and name.

The system roles are used to define your basic access rights to the system. The actual permissions are defined using the context based roles (relations). Relations are used to authorise users based on their role in the academic structure and relation to an object in that structure.

E.g. When John Doe gets assigned the role “module coordinator” of a certain module, a relation is established between John Doe and this specific module. This relation grants John Doe access to that specific module with the permission scheme of the role 'module coordinator'. Other modules may be accessible by the permission scheme assigned to the system role user, but these will be limited to read-only and not provide the same permissions as for the module assigned as module coordinator.

The context based roles (relation types) used in the academic structure can be defined and via the Relation type menu-item.

The relation type menu allows for the definition of context based roles, but also allows for the definition of 'assignment' roles to assign HR roles to a person that are used in the workforce planning module. E.g. a person with an HR role of researcher will standard have a division of 80% research and 20% education.

Relation types can be managed using the Add, Edit (select) and Delete buttons.

The configuration of a relation type supports the following attributes:

• ‍Object type - The object type defines for which object the relation are defined. For all objects the relations defined can be assigned rights on the object with the exception of the object type assignment which is used for resource planning and management.
  
  Supported options are:
  - Assessment
  - Assignment: Used to allocate persons with an assignment to an organisation unit. The assignment can be used in resource and staffing management and allows for the definition of rules based on the relation. E.g. a researcher has 40% lecture time, a lecturer has 100% lecture time.FacultyInstitutionMethodModuleModule groupOrganisationPersonsProgramme (CROHO programme for the Netherlands)StudyQualificationAssessment
  - Faculty
  - Institution
  - Method
  - Module
  - Module group
  - Organisation
  - Persons
  - Specification
  - Study
  - Qualification
• ‍External ID - Unique ID used for integration with external systems
• ‍Code - Internal code, used for display purposes
• ‍Name - The descriptive text for the relation type used for display purposes
• Condition -Limit the visibility of the relation type using an, e.g. :(module)typeId = 'MOOC' and not(:faculty in ('SCIENCE')) will only show the relation type in case the module type is MOOC and not in the Science faculty.
• Allocation type - Specify the allocation type that will be used in the resource and planning calculation of hours required
  • ‍Assigned to a fixed amount of hours: the person assigned requires a fixed amount of hours to fulfil the task, e.g. module coordinator task is 80 hours per semester
  • ‍Assigned for a percentage: the person assigned requires a percentage of the calculated hours for the complete task, e.g. the lecturer delivers 50% of the teaching hours calculated (lecture, workgroup, ...)
  • ‍Assigned for a fixed amount of students: the person assigned requires a fixed amount of hours per student to fulfil the task, e.g. a paper reader requires 6 hours per paper/students
• ‍Persons - Indicator if the relation defined can be assigned a user
• ‍Groups - indicator if the relation defined can be assigned a group/team
• Provides education - indicator if the relation is considered to provide education. Users with a role marked as provides education will be calculated as sucht in the workload management formulas, and will allow the user to be assigned to individual activities defining the schedule preferences
• ‍Ignore - indicator if the relation should be ignored
• ‍Selectable in report -indicator if the relation is selectable in the list reports (that allow selection of additional fields and export of date)
• ‍Visible in report - indicator if the relation is default selected in the list reports (that allow selection of additional fields and export of date)
• ‍Default start date - indicator if on adding a user to a role a default start date (start of academic year) is used
• ‍Minimum - defines the minimum number of required relations for this type.Is used for validation / information on 'incorrect defined relationships'
• ‍Maximum - defines the maximum number of required relations for this type.Is used for validation / information on 'incorrect defined relationships'
• ‍Sequence -The order the list of relations is offered to the user in the user interface
• ‍When maximum gets exceeded - Action to be performed in case the maximum gets exceeded. Options supported:
  • ‍Only show a warning: Show warning, allow save and proceed
  • Disallows saving the relation: Show an error, user has to modify in order to save and proceed‍
• Start date - date from which the relation is available in the user interface.
• ‍End date - date till which the relation was or will be available in the user interface
• ‍Show budget on Dashboard - show budget information for this role on the dashboard (in case the budget functionality is selected)

Access to functionality in Curriculum can be modified via the Access rules menu-option. Selecting this menu-item shows an overview of all defined roles and relations and allows for the configuration of the permission scheme for the roles.

The permission scheme manager shows the defined context based roles on the left. Just select the role to manage the permission scheme.
Selection of multiple roles simultaneously is supported, to allow for comparing and modifying multiple roles at the same time.

Permissions can be assigned without restriction or with restriction. The screenshot shows a green checkbox which indicates the defined permission is without restrictions, where the orange checkbox indicates the assigned permission is restricted.

The above detailed configuration of the rules is accessible via the 'pencil-button' next to the selected role. In case the permission is with restriction additional information is shown in the columns Restricted to, And similar in and Condition.

Selecting the assigned permission will open the configuration to define the restrictions:

• Operation - The permission that must be added/modified to the add a restriction.
• Restricted to - Specify to which object type the right is restricted. In case no object type is specified the right is allowed to all object types.
  For example, if the right 'view descriptions' is allowed without restriction this means that the person is allowed to see descriptions for study, module group, module, etc.
• And similar in - This rule is used to set this rule within a specific context. Mostly used is Year, to set this rule within the context of an academic year
• Condition - Limit the permission based on a condition, e.g only allow this permission if the module is of type MOOC via :module(typeId) = 'MOOC'
• Process - Limit the permission to a specific status in the process. This allows for allowing the module coordinator edit rights on a module and restrict it to the 'maintain' phase, and deny this permission once the module is in another status.
• When in status - Specifies the status in the process the permission is granted.

Permissions can be defined assigning permissions to a role (relation type). Supported permissions are grouped into four categories.

View permissions

The view permissions are used to define the rights for users to view specific information, for instance to allow view rights to module uploaded documents and not allow view rights to cost of module information.

Supported view permissions are:

VIEW
VIEW_ACCESS_RULES
VIEW_ADDITIONAL
VIEW_ADVICE
VIEW_APPRAISALS
VIEW_ASSESSMENTS
VIEW_ASSETS
VIEW_ASSIGNMENTS
VIEW_AVAILABILITY
VIEW_CAPACITY
VIEW_CHANGE
VIEW_COST
VIEW_COST_DIVISION
VIEW_CREDITS
VIEW_DESCRIPTIONS
VIEW_DOCUMENT
VIEW_EFFORTS
VIEW_EFFORTS_CORRECTION
VIEW_EVALUATION
VIEW_FEEDBACK
VIEW_GROUPS
VIEW_HOURS_MODULE_REPORT
VIEW_HOURS_PERSON_REPORT
VIEW_ITEMS
VIEW_LINKS
VIEW_MESSAGES
VIEW_METHODS
VIEW_MODULES
VIEW_NOTES
VIEW_OBJECTIVES
VIEW_OFFERINGS
VIEW_ORGANISATIONS
VIEW_SPECIFICATIONS
VIEW_PERSONS
VIEW_QUALIFICATIONS
VIEW_RELATIONS
VIEW_RESOURCES
VIEW_SCHEDULE
VIEW_STRUCTURE
VIEW_STUDIES
VIEW_STUDYABLE
VIEW_SUBJECTS
VIEW_SUBJECTS_REPORT
VIEW_TASKS
VIEW_TASKS_PERSONAL
VIEW_TASKS_CORRECTION
VIEW_WORKLOG
VIEW_REPORT
VIEW_SCHEDULE_ACTIVITIES
VIEW_SCHEDULE_PROGRESS
VIEW_PROCESS_PROGRESS
VIEW_CHANGE_REPORT_TEMPLATES
VIEW_PROCESS_MANAGEMENT
VIEW_SCHEDULE_PREFERENCE_REPORT
VIEW_MODULE_PREVIEW
VIEW_CUSTOM_01
VIEW_CUSTOM_02
VIEW_CUSTOM_03
VIEW_CUSTOM_04
VIEW_CUSTOM_05
VIEW_CUSTOM_06
VIEW_CUSTOM_07
VIEW_CUSTOM_08
VIEW_CUSTOM_09
VIEW_CUSTOM_10

The VIEW_CUSTOM permissions can be used freely by the administrator to define own rules that can be used for specific restrictions.

Edit in workflow permissions

The edit in workflow permissions are used to define the rights for users to edit specific information in a workflow. Similar edit permissions are provided to set permissions for edit outside the workflow (in the tabular view). This allows for restricting users edit right only to workflow and not in tabular view.

Supported edit in workflow permissions are:

EDIT_ADVICE_WORKFLOW
EDIT_WORKFLOW
EDIT_MODULE_WORKFLOW
EDIT_ADDITIONAL_WORKFLOW
EDIT_APPRAISALS_WORKFLOW
EDIT_ASSESSMENTS_WORKFLOW
EDIT_ASSETS_WORKFLOW
EDIT_ASSIGNMENTS_WORKFLOW
EDIT_CAPACITY_WORKFLOW
EDIT_CREDITS_WORKFLOW
EDIT_COST_WORKFLOW
EDIT_COST_DIVISION_WORKFLOW
EDIT_DESCRIPTIONS_WORKFLOW
EDIT_DOCUMENT_WORKFLOW
EDIT_EFFORTS_WORKFLOW
EDIT_ITEMS_WORKFLOW
EDIT_LINKS_WORKFLOW
EDIT_METHODS_WORKFLOW
EDIT_METHODS_EXTRA_WORKFLOW
EDIT_MODULE_GROUP_MODULE_WORKFLOW
EDIT_MODULE_GROUP_MODULE_GROUP_WORKFLOW
EDIT_NOTES_WORKFLOW
EDIT_OBJECTIVES_WORKFLOW
EDIT_OFFERINGS_WORKFLOW
EDIT_RELATIONS_WORKFLOW
EDIT_RESOURCES_WORKFLOW
EDIT_SCHEDULE_WORKFLOW
EDIT_SCHEDULE_PREFERENCE_WORKFLOW
EDIT_STRUCTURE_WORKFLOW
EDIT_STUDY_MODULE_GROUP_WORKFLOW
EDIT_SUBJECTS_WORKFLOW
EDIT_TASKS_WORKFLOW
EDIT_WORKLOG_WORKFLOW

Edit (outside workflow) permissions

The edit permissions are used to define the rights for users to edit specific information outside a workflow (in the tabular view). Similar edit permissions are provided to set permissions for edit via the workflow. This allows for restricting users edit right only to workflow and not in tabular view.

Supported edit permissions are:

EDIT
EDIT_MODULE
EDIT_ADDITIONAL
EDIT_ADDITIONAL_FUNDING
EDIT_ADVICE
EDIT_APPRAISALS
EDIT_ASSESSMENTS
EDIT_ASSETS
EDIT_ASSIGNMENTS
EDIT_CAPACITY
EDIT_CREDITS
EDIT_CODE
EDIT_COST
EDIT_COST_DIVISION
EDIT_DESCRIPTIONS
EDIT_DESCRIPTIONS_EXTRA
EDIT_DOCUMENT
EDIT_EFFORTS
EDIT_EXTERNAL_ID
EDIT_ITEMS
EDIT_LINKS
EDIT_METHODS
EDIT_METHODS_EXTRA
EDIT_MODULE_GROUP_MODULE
EDIT_MODULE_GROUP_MODULE_GROUP
EDIT_NOTES
EDIT_OBJECTIVES
EDIT_OFFERINGS
EDIT_RELATIONS
EDIT_RELATIONS_DATE
EDIT_RESOURCES
EDIT_SCHEDULE
EDIT_SCHEDULE_PREFERENCE
EDIT_STRUCTURE
EDIT_STUDY_MODULE_GROUP
EDIT_SUBJECTS
EDIT_SUBJECT_TYPES
EDIT_TASKS
EDIT_VACANCIES
EDIT_WORKLOG

Custom permissions

The custom permissions can be used freely by the administrator to define own rules that can be used for specific restrictions.
The administrator can rename the custom specification to a more 'meaningful' name in context of the setup.

Supported custom permissions are:
‍
OPERATION_01
OPERATION_02
OPERATION_03
OPERATION_04
OPERATION_05
OPERATION_06
OPERATION_07
OPERATION_08
OPERATION_09
OPERATION_10

Other (generic) permissions

The other (generic) permissions are used to define the rights for users to specific functions in the system.

Supported other (generic) permissions are:

DOWNLOAD_OER
CREATE
CREATE_ASSESSMENT
CREATE_GROUP
CREATE_MODULE
CREATE_ORGANISATION
CREATE_PERSON
CREATE_QUALIFICATION
CREATE_RULE
CREATE_SIMULATION
CREATE_SPECIFICATION
CREATE_STUDY
DELETE_WITH_HISTORY
COMPLETE_WORKFLOWS
BULK_CHANGE
ADMIN_OBJECT
VERIFY_OBJECT
REJECT_OBJECT
INVOKE_HOOK
EXPORT
EXPORT_DOCUMENT
APPROVE
SEND_EMAIL
LOGIN_AS
IMPORT
IMPORT_REGISTRATION
‍

The system supports the definition of teams (user groups). Similar to a user, teams can be assigned to a context based role. This allows for defining teams globally, maintaining the membership (by the team owner) instead of allocating individual users to a role.

Teams can be defined by the administrator, or created automatically via the API.
Once a team is defined and allocated at least one member (a user), the user can manage the team by adding / removing other users.

The administrator can click on a team or use the Add and Delete button to manage teams.

The configuration of a team supports the following attributes:

• ‍External ID - The unique identifier for the team, used for integration purposes.
• ‍Code  - The unique identifier for the team used for display and unique identification of the team in Curriculum
• ‍Name  - The name of the team, used for display purposes in selections of teams by users.
• ‍Start date - The date from which the team is available for selection in the system
• End date - The date till which the team is/was available for selection in the system. The end date is considered a 'soft delete'.