Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
67 changes: 67 additions & 0 deletions docs/advanced/administrators/user_access.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
# Base User Roles

There are currently 3 base user roles:

## STUDENT

Users with the STUDENT role have access only to student pages. There is only one class or type of STUDENT role, however access to specific modules is subject to enrollment as a student on that module. Enrolment of students is done by a teacher.

## TEACHER

Users with the TEACHER role have access, in addition to student pages, to teacher pages. This includes, for example, the teacher home page (`/teacher`). Within TEACHER pages, users only have access to modules to which they are linked as a teacher or tutor.

Access as a _teacher_ requires enrollment as a teacher on the relevant module, which can be done in two different ways:

- by teachers on that module with the relevant permissions.
- by ADMIN users in the ADMIN pages.

Access as a _tutor_ to teacher pages of a module is by a link to a student who is enrolled on that module. The link is via a ['global tag'](user_tags.md), which is managed by an ADMIN.

On each module that a user is enrolled as a teacher, they will be assigned a teacher _role_. The number of different roles (such as 'MODULE OWNER' or 'TEACHING ASSISTANT'), and their respective permissions, is configurable by ADMIN users. Each role is defined by which permissions are, or are not, assigned to the role. Permissions include access to pages, tabs, menus, and features (such as enrolling or viewing statistics).

Permissions that can be assigned to a teacher role are visible when enrolling a teacher. The pop-up shows which permissions exist, which roles have been configured, and their intersection. An example is below.

![](permissions_example.png)

Permissions are part of the application. Roles are configured by ADMIN users on the app.

## ADMIN

Users with the ADMIN role have, in addtion to TEACHER and STUDET privileges, access to all admin pages. There is only one class of ADMIN.


# Teacher Roles

There are two fundamental TEACHER roles: OWNER and CUSTOM, with further configurations are possible through the CUSTOM role type, which are managed by ADMIN users. There is also a PERSONAL TUTOR role, which is an independent way to allocate permissions.

## OWNER

A fixed role. ADMIN can modify the role’s name, but cannot delete the role or change its permissions.

OWNER is assigned automatically to the user who creates a new module instance, but it may also be reassigned to other users with TEACHER (or ADMIN) base roles.

## CUSTOM

ADMINS can configure an unlimited number of custom roles, which can then be assigned to teachers by ADMIN, and by TEACHERs with relevant enrollment permissions on a given module.

# Personal tutor

Personal tutor is listed in the ADMIN panel with other teacher roles, but it is an independent access mechanism derived from student–tutor relationships (tutor access is not a teacher role).

Permissions for personal tutor always includes `View student data`. Other permissions are controlled by ADMIN users and can be enabled or disabled. Whatever permissions are applied, apply to all personal tutors - there is only one configuration of personal tutors.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small clarification suggestion: it might be worth noting here that View student data for tutors is scoped to their tutor group only, and is not the same as teacher View student data (which applies to all students).

This is explained later, but mentioning it here could avoid confusion when reading this section in isolation.


### Assigning a personal tutor

Personal tutors are implicitly assigned by linking a teacher to a Global (student) Tag. For example a Global Tag named '2028' could be applied to a cohort of students, and be linked to a teacher who is then a 'tutor'.

Tutor access to a module for a TEACHER (or ADMIN) requires at least one STUDENT in that module to share a Global Tag with the TEACHER (or ADMIN). Access to the module is then restricted by the permissions assigned to the PERSONAL TUTOR role.

Although the tutor role includes the `View student data` permission, that permission applies _only_ to students within the same tutor group (i.e. those sharing the same Global Tag); an exception is if the same user also has a TEACHER ROLE, on the same module, with `View student data` permission. Access to student data for tutors differs from normal TEACHER access, where permissions apply to all students within the module.

Note that a TEACHER can be enrolled on a module with a TEACHER role, and additionally by being linked as a TUTOR. Permissions then combine and are _additive_ (a permission from either role is sufficient for permission to be granted).

## Moderator access

Moderator features require a TEACHER role to include the `Moderate student submissions` permission. TEACHER roles with these permissions cannot be assigned by other TEACHERs (including OWNERs), but can only be assigned by an ADMIN.

Moderators have privileged access to staff-specific comments on MEQ, and this privilege is above that of a module owner. Details available in [../student/MEQ#access-to-meq-data](../../../student/MEQ/#access-to-meq-data).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One clarification point: we currently also have custom teacher roles with owner-like names (e.g. “Owner-moderator”), which are not the fixed OWNER role type.

In this sentence, “module owner” seems to refer specifically to the fixed OWNER role. It may be worth making that explicit to avoid confusion with owner-named custom roles.

5 changes: 5 additions & 0 deletions docs/advanced/administrators/user_tags.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
Students can be allocated a module tag, which only applies within the relevant module; and/or a global tag, which applies across all modules.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small clarification suggestion:
since global tags are used to define tutor groups and tutor access, it may help readers if this is stated explicitly here, e.g.

“Global tags are used to group students for tutor access.”


Tags help filter data analytics and manage user access to student data.

Docs on applying tags will follow.
7 changes: 5 additions & 2 deletions docs/advanced/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,9 @@ Response areas are components in the frontend where student users can enter a re

[Response areas - overview](response_areas/overview.md){ .md-button .md-button--primary style="width: 400px;"}

## Administrators
## Administrators

This section contains documentation for users responsible for managing tenant-level configuration and advanced operational behaviour in Lambda Feedback.

[Administrators](administrators/user_access.md){ .md-button .md-button--primary style="width: 400px;"}

Content to be added.
3 changes: 3 additions & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -84,6 +84,9 @@ nav:
- Quickstart: "advanced/chat_functions/quickstart.md"
- Testing Functions Locally: "advanced/chat_functions/local.md"
- Chat Functions Information: "advanced/chat_functions/info.md"
- Administrators:
- User Access: "advanced/administrators/user_access.md"
- User tags: "advanced/administrators/user_tags.md"

# Configuration
theme:
Expand Down