Manage Your Users

This article focuses on the the basics of creating users, role assignments, enrolments, and user information & status management.

TOPICS

• Creating a User

  • Adding a New User: Manual Authentication

  • Bulk User Management via CSV

  • Email Based Self-Registration

  • Adding Users from Other Systems via Single Sign-On (SSO)

• Assigning Roles and Permissions
  • Roles and Contexts
    • Types of Site Contexts
    • Standard Roles

• • Assigning System Roles
    • Assigning Other System Roles by CSV
• How Do I Delete a User?
  • Deleting a User
  • Suspending a User Account
  • Disabling a User Account: "No Login"
• Messaging Site Users
  • Messaging Setting for All Users
  • Enabling / Disabling Site-Wide Messaging
  • Notifications

---

Creating a User

Lambda Learn offers several options to add users. When user accounts are created on a site, the process is called authentication and when users join a course, the process is called enrolment.

Typically only the administrator is allowed to add (authenticate) users to a site. Course creators or teachers are then able to add students, by way of enrolment, to their course. They do not have permission to add users to the site, unless they are given that capability by the administrator. 

 Adding a New User: Manual Authentication

 As an administrator,  you can add users one at a time in the Add a new user page: Site administration > Users > Accounts > Add a new user. 

The required user profile fields are: Username, First name, Surname and Email address.  The user password may be manually entered, or you can let the system "Generate password and notify user" via email.

There is also a "Force password change" setting that prompts the user the user to change their password upon login. Of course, the user's password. It is subject to the password policy you have set in Settings > Site administration > Security > Site policies.

Administrators can create new user profile categories and fields in Administration > Site administration > Users > Accounts > User profile fields.  Profile fields may be a menu of choices, text area, text input or a checkbox and may be required or not.

The process of adding one user manually is called Manual authentication. This setting is enabled by default. You can lock certain fields, set password expiry dates and other configure other settings from Site administration > Plugins > Authentication > Manual accounts.

Back to TOPICS

 Bulk User Management via CSV

If you need to deal with many users at a time, the Upload users feature will allow for quicker management: Site administration > Users > Accounts > Add a new user.

The upload users file is typically referred to as a CSV (comma separated values) text file. It has fields separated by a comma (or other delimiter) ONLY - no spaces.

• • You can use a spread sheet program, such as MS Excel or Google Sheets, to create the file with the required columns and fields. Then save the file as "CSV". These files can then be opened with a simple text editor (eg, Notepad++) for verification.
  • The first line of the *.csv file must contain at least the required field names: username,firstname,lastname,email. 
  • The subsequent lines (user records) contain information about each user. For example: slumbergh,Sam,Lumbergh,slumbergh@example.com

 

The batch user upload method also allows you to accomplish other bulk user related actions such as:

Back to TOPICS

  Email Based Self-Registration 

In the event where you want your users to create their own, the Email-based self-registration provides that workflow. The default required registration fields are Username, Password, First name,  Surname, and Email. 

 

Back to TOPICS

  Adding Users From Other Systems via Single Sign-On (SSO)

It is possible for users to connect to Lambda Learn  via single sign on (SSO) from other systems. The settings for these may be found in Site administration > Plugins >Authentication > Manage authentication and include:

• • CAS server (SSO) - account details are located on an external CAS server.
  • External database - account details are located on an external database.
  • LDAP server - account details are located on an external LDAP server.
  • Shibboleth - account details are located on an external Shibboleth server.

  • Web services authentication.

Back to TOPICS

---

Assigning Roles and Permissions

To fully understand what users can do in Lambda Learn, we need to define 4 key terms related users and abilities in the system:

• Capability: A configurable aspect of program behaviour. LAMBDA LEARN (Moodle) has 100s of capabilities. Each capability has a computer friendly name like mod/forum:rate and a human-friendly name like "Rate posts."
• Permission: Permissions are paired with each capability. There are four possible permission values: Allow, Prevent, Prohibit and Not set/Inherit. (It is called Not-set when defining roles, and Inherit when overriding permissions.)
• Role: A named set of permissions that are associated with each capability. For example. the "Teacher" and "Student" roles come with the standard LAMBDA LEARN (Moodle) install.
• Context: A functional area or space in LAMBDA LEARN (Moodle) where roles can be assigned. Contexts have a hierarchy. There is a hierarchy of contexts which helps locate and define a specific space. Generally speaking, this hierarchy allows a lower context to receive information from a higher context. For example, an LMS site is one context and that contains a number of other contexts within it. A category is a context, within a site context, that contains courses and sub-categories that have a context of their own.  Courses have activities or resource.

The combination of roles and context define a specific user's ability to do something on any page.  A context might contain other contexts and Roles can be assigned to each context. Apart from the manager and course creator, users do not normally have a site-wide (or system) role. 

Because of the way LAMBDA LEARN works, assigning roles is done for a particular context. Site and course are examples of two different contexts.

Roles and Contexts

A context is combined with role permissions to define a User's capabilities on any page in LAMBDA LEARN. Typically contexts have their own organization structure which allow a User's role to be passed along to the context "below" but not to the one above it. 

The image below shows a few contexts and their relationships. The "System" or LAMBDA LEARN site is the overall context. The User is defined initially in this context. The System context has 2 contexts under it, with other context under them in which roles can be assigned: 

• The Front page context has an activity module context and a block context within it.
• The course Category context has a Course context within it. The course context has an activity module context and a block context within it.

It is possible to assign a user different permissions based upon a specific context. For example, a user might be given the role of student for a course but be given a teacher's role in the context of one specific forum. Or a user can be a teacher of one course and a student in another course.

Many LAMBDA LEARN contexts have a place to grant exceptions to specific roles within that context. Those exceptions are non-transferable from that context. That is, an exception can be applied to the next context downward, but cannot applied sideways nor upward from that context. 

Types of Site Contexts

System	To assign a role in the system context, go to Site administration > Users > Permissions > 'Assign system roles'. Any roles assigned here apply across the whole site. It makes sense therefore that only roles that need this functionality can be assigned here. The Manager role and Course creator role are examples of two such roles. Assigning a teacher or student here would result in their being able to teach/study in every single course on the site, which is not usually desirable.
Category (Course)	Users may be enrolled in a course category to save enrolling them in each individual course in that category.
Course	A course can have many contexts in its space. These might include lesson, assignment, forum and quiz modules and blocks.
Activity	An example of this is assigning a student the teacher role locally in an individual activity like a forum so they can moderate their classmates' posts while still retaining the student role in the rest of the course.
Block	You may wish to assign roles to a block if, for instance you want specific people to see the block but for it to be hidden from others.
User	The user context is used for roles such as mentor, team leader or the Parent role. The role to be assigned must have 'User' ticked as the context type where it is to be assigned. To assign a user the role of mentor in the context of their mentee, click the mentee's profile, then Preferences then 'Assign roles relative to this user'. If a mentor has lots of mentees, the role of mentor can be assigned to them all in one go as follows: Put all mentees in a cohort Go to Site administration > Users > Permissions > Assign user roles to cohort.

Standard Roles

By assigning a role to a user in a certain context, you grant them the permissions contained in that role for the current context and all lower contexts. So when you create a new role or tweak a pre-existing role via Administration > Site Administration > Users > Permissions > Define roles you are asked in which context(s) you want the role to be assigned.

• • Site administrator. Site administrators have permissions to do anything. It is recommended that you don't have lots of admins on your site. Good practice is to only have one or two, then give everybody else roles such as Manager, with only the permissions that they require.
  • Manager. The default Manager role enables users assigned the role to access courses and modify them, as well as perform certain administrative level tasks related to courses, users, grade settings, etc. - a lesser administrator role
  • Course creator. A user assigned the role of course creator can (as the name suggests!) create a course. If the setting "Creators' role in new courses" (creatornewroleid) in Site administration / Users / Permissions / User policies is left as default (teacher), then the course creator is enrolled as a teacher in the course they have just created and can then edit the course settings and enrol other users. A course creator can also view hidden courses.
  • Teacher. Teachers can do almost anything within a course, including adding or changing the activities and grading students. By default, teachers can also assign a Non-editing teacher role and a Student role to other users. 
  • Non-editing teacher.  A non-editing teacher is able within a course to view and grade students' work, but may not alter or delete any of the activities or resources. This role might typically be given to a classroom assistant for example. In courses where groups are used, the non-editing teacher may well be responsible for one particular group and will not need access to other groups.
  • Student. A user with the Student role in can participate in course activities and view resources but not alter them or see the class gradebook. They can see their own grades if the teacher has allowed this.  Once learners have enrolled or been enrolled into at least one course they then only see their own courses in the My Courses section of the navigation block or via their dashboard. 
  • Guest. Lambda Learn has a built-in "Guest account". Visitors can log in as guests using the "Login as a guest" button on the login screen and enter any courses which allow guest access. In addition, logged-in users can enter any courses which allow guest access without being required to enrol. Guests ALWAYS have "read-only" access - meaning they can't leave any posts or otherwise mess up the course for real students.
  • Authenticated user. When a user logs in, they are automatically assigned the role of authenticated user. A user will have additional roles as well as the authenticated user role according to where they are in Lambda Learn , such as student in a course. By default, authenticated users have permission to edit their own profile, send messages, blog and do other things outside of courses.
  • Authenticated user on the front page role - a logged in user role for the front page only

Roles can be inherited. For example if a user is assigned a Teacher role in a specific course category, then the user will have this role in ALL courses within the category. 

Roles will only work if the role assignment is made in the correct context. Some examples: a Teacher role should be assigned to a user in the course or course category context, a Forum moderator for a particular forum should be assigned in that specific forum.

Back to TOPICS

  Assigning System Roles

 Lambda Learn allows for the assignment of additional site administrator. But as site administrators have permissions to do anything, It is recommended that you don't have lots of admins on your site. Good practice is to only have one or two, then give everybody else roles such as Manager, with only the permissions that they require.

Users may be assigned the role of site administrator by another site administrator in Site administration > Users > Permissions > Site administrators, but the role itself cannot be edited (or deleted!).

Site administrators are assigned via a special page: Administration > Site Administration > Users > Permissions > Site Administrators.  Select the name from the right and move it over to the left. 

 

Back to TOPICS

 

Assigning  System Roles by CSV

Where certain custom roles are applied in the system context, it is possible to upload users to that role in bulk by adding the field sysrole1 (etc) to a CSV file.

When previewed, there is a column indicating their system role:

Once uploaded, the users are present on the 'Assign system roles' screen:

Back to TOPICS

 

---

 

How Do I Delete a User?

When managing users in a system, it is important to know the types of user status available in the system and how they differ.

Back to TOPICS

---

 

Messaging a User

Unless disabled by the administrator (in Site administration > Messaging > Messaging settings), teachers, students and other users may send and receive private messages via Lambda Learn (Moodle). This is in addition to receiving notifications about assignments, forum discussions etc.

 

Enabling / Disabling Site-Wide Messaging

The personal messaging system in Moodle is enabled by default. It may be disabled by a site administrator from Site administration > Messaging > Messaging settings.

From 'Messaging settings', the administrator can "Allow site-wide messaging" (disabled by default). If this setting is enabled, users on the site can view all other users when selecting someone to message and can choose to accept messages from anyone on the site.

 

  Messaging Settings for All Users

• Users can decide how they want to be notified of new messages and event notifications by editing their messaging preferences page, which they can access either from the Preferences link in the user menu or from the gear icon in the messaging/notifications menus. 
• Which options users see depend on what has been enabled by the administrator.  Because users might have many different messaging options, they are ordered into different components - for example, activities, system, enrolments etc. Example notifications preferences screen - student view

Back to TOPICS

 

  Notifications

Notifications alert teachers, students and other users about events in the LMS such as new forum posts, assignments needing grading or badges awarded.

• Along with a visible alert to new events in the notifications menu, users can configure how they are notified of new events from their notification preferences page accessed from the user menu or from the gear icon in the notifications menu.
• Notifications may be sent via the web (when logged in the LMS), email and mobile (for Mobile-enabled sites).
• Web offline options are for setting whether a user is notified when they next log in to the LMS.