Hierarchy – Roles and Permissions (Sysadmin)
TABLE OF CONTENTS
- Introduction
- The three permission layers
- How the layers interact
- Feature access by permission layer
- Giving teachers hierarchy administrator rights
- Custom course roles
- Troubleshooting common access issues
Introduction
Access control in itslearning operates across three distinct layers: the user's profile, their role within the hierarchy, and the role assigned to them within each course. Understanding how these layers interact is essential for diagnosing unexpected permission behaviour and for making deliberate decisions when configuring access.
Note: Hierarchy roles must not be confused with profiles or course roles. They are separate concepts operating at different levels of the system.
Important: In most cases, users are created and maintained through a SIS integration. Manually changing a user's role or hierarchy role in itslearning so that it no longer matches the integration file is not recommended, as this can cause problems with synchronisation, permissions, and course membership.
The three permission layers
Profiles
A profile is assigned to a user at the system level and defines the overall framework for that user's experience and access across the platform. The profile controls standard rights and the UI experience, and determines which roles the user can be assigned within courses.
Standard profiles include:
- Student
- Teacher
- Administrator
Profiles are typically set via SIS import or through the administration interface, and apply across the entire platform.
Hierarchy roles
A hierarchy role determines what a user can see and do within a specific hierarchy node and its sub-nodes. There are four hierarchy roles:
| Role | Notes |
|---|---|
| Administrator | Unlocks administrative features scoped to the user's hierarchy. The local administrator is responsible for managing the school's dashboard. |
| Employee | Standard staff membership within the hierarchy. |
| Student | Standard learner membership within the hierarchy. |
| Guest | External user with limited access within the hierarchy. |
Note: Hierarchy roles cannot be changed.
Course roles
Course roles are assigned per course and represent the most flexible layer of the permission model. A user has one global profile, but can hold a different course role in each course they are a member of.
Standard course roles include Teacher, Student, and Guest. In addition, itslearning supports custom course roles, which are described in the Custom course roles section below.
How the layers interact
The key principle is that the course role determines what a user can actually do within a course — not their global profile alone. The most specific context always takes precedence:
Priority rule: Course role > Hierarchy role > Profile
A user's profile defines their general access. Their hierarchy role adjusts what administrative features they can see. Their course role determines what they can do inside each specific course.
The following examples illustrate how this works in practice:
| Profile | Course role | Result |
|---|---|---|
| Teacher | Student | The user behaves as a student in that course and cannot edit content, regardless of their global profile. |
| Teacher | Custom role (e.g. Course Admin) | The user receives extended rights in that course, such as managing participants or editing content, depending on the role definition. |
| Administrator | Student | The user's course UI and rights are those of a student in that course. Access via the administration panel is unaffected. |
Note: The same user can hold a Teacher role in one course, a Student role in another, and a custom role in a third. This is fully supported and common in practice.
Feature access by permission layer
Access to administrative features in itslearning is controlled by a combination of profile permissions and hierarchy role. The relationship between these varies by feature area. The tables below are based on testing with a Teacher profile and document the confirmed behaviour for the listed features.
Note: The tables below cover the most commonly encountered features and are not exhaustive. If a menu item is visible but the page appears empty or non-functional, check both the user's profile permissions and their hierarchy role.
Features not visible without hierarchy administrator role
The following features do not appear in the Administration menu unless the user holds the Administrator role in a hierarchy.
| Feature | Notes |
|---|---|
| Users and Access management | Data scope and operations are restricted to the user's hierarchy. Without this setting, a user can still enrol others to courses within their hierarchy, but operations are otherwise limited. |
| Logins report | Must also be enabled in site settings. There is no separate profile setting for this report. |
| Course visits report | Must also be enabled in site settings. There is no separate profile setting for this report. |
| Storage distribution report | Must also be enabled in site settings. There is no separate profile setting for this report. |
| Individual Learning Plans | Menu item is hidden until the user holds hierarchy administrator role. |
Features visible with profile permission but limited or non-functional
The following features appear in the Administration menu with a profile permission alone, but require hierarchy administrator rights to function fully.
| Feature | Behaviour with profile only | Hierarchy administrator role required for |
|---|---|---|
| Course management | Page is visible but non-functional. | Full functionality. |
| Hierarchy | Can view hierarchies the user is a member of. Cannot add or edit. | Adding and editing hierarchy nodes. |
| Booking management | Page is visible. Displays a notification that the user must be an administrator in an organisation to manage bookable resources. | Managing bookable rooms and equipment. |
| Trash can | Page is visible but non-functional. Which tabs appear depends on the user's profile settings. See the Trash can note below. | Permanent deletion of courses. Scope is restricted to the user's organisation. |
| Supervisors | Page is visible but non-functional. | Full functionality. |
Quick reference: Trash can tab visibility
The trash can page is visible with a profile permission alone, but which tabs appear and what can be permanently deleted depends on a combination of profile settings and hierarchy role:
- Course deletion: requires hierarchy administrator role. Scope is restricted to the user's organisation.
- Users tab: appears when the profile setting User and access rights management is enabled. Allows permanent deletion of users in the user's organisation(s).
- Project deletion: requires the profile setting Project management to be enabled.
Giving teachers hierarchy administrator rights
When a user with a Teacher profile is assigned the Administrator role within a hierarchy, they gain access to a specific set of administrative features scoped to that hierarchy. This is distinct from a full system administrator account.
A teacher given hierarchy administrator rights will gain:
- Users and Access management — the menu item becomes visible, with data scope and operations restricted to their hierarchy.
- Individual Learning Plans — the menu item becomes visible.
- Logins report, Course visits report, and Storage distribution report — these menu items become visible if they are enabled in site settings.
- Trash can (course deletion) — the ability to permanently delete courses within their organisation. Which additional tabs appear in the trash can depends on other profile settings. See the Trash can note above.
Important: Granting a teacher hierarchy administrator rights gives them the ability to permanently delete courses from your organisation via the trash can. If the user also holds the User and access rights management profile permission, they will additionally be able to permanently delete users. Ensure this is intentional before assigning the role.
Custom course roles
itslearning supports custom course roles, which allow administrators to define role configurations that give more or fewer permissions than the standard Teacher or Student roles. Custom roles are assigned at the course level, the same as standard course roles.
Examples of custom role configurations include:
- Reviewer
- External teacher
- Department admin
Custom roles provide significant flexibility but can also introduce complexity. Unexpected permission behaviour is often caused by a combination of imported roles, manual changes, and custom role definitions with overlapping or unclear permission sets.
Troubleshooting common access issues
A teacher cannot edit content in a course
Symptom: A user with a Teacher profile cannot edit course content.
Cause: The user has been assigned the Student course role in that specific course. The course role overrides the global profile.
Solution: Check the user's course role in the affected course and update it to Teacher or the appropriate role.
A student can edit content they should not be able to access
Symptom: A user with a Student profile can edit or manage content in a course.
Cause: The user has been assigned a custom course role that includes edit permissions.
Solution: Review the user's course role and the permission set defined for that custom role.
An administrator cannot perform actions in a course
Symptom: A user with an Administrator profile cannot perform expected actions within a specific course.
Cause: The user's course role limits their experience within that course. Course role takes precedence over global profile for in-course actions.
Solution: Check the user's course role and update it as required.
Inconsistent behaviour across features
Symptom: A user can access some administrative features but not others, despite having similar settings to another user.
Cause: Access control requirements vary across features. Some features require only a profile permission; others require the hierarchy administrator role; others require both. Additionally, custom course roles with partially defined permissions can produce inconsistent results.
Solution: Check the user's profile, their hierarchy role, and any custom course roles they hold. Compare against the Feature access by permission layer table above.