This article focuses on the the basics of creating users, role assignments, enrolments, and user information & status management.
- Creating a User
- Assigning Roles and Permissions
- How Do I Delete a User?
- Messaging Site Users
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.
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,email@example.com
The batch user upload method also allows you to accomplish other bulk user related actions such as:
- The "password" field is optional if the 'New user password' setting on the upload screen is set to "Create password if needed and send via email". However, if you selected the "Field required in file" setting, then you must provide the required password that meets the requirements your site's Password policy.
- To force password change for a particular user, set the password field to changeme. If omitted, a password will be generated for each user (during the next Cron job) and welcome e-mails sent out. The text for the welcome e-mail is in the language settings in Site administration > Language > Language customisation with a String identifier of 'newusernewpasswordtext'.
- It is usually not necessary to upload users in bulk with Upload users. To keep maintenance work down you should first explore forms of authentication that do not require manual maintenance. See ADDING USERS FROM OTHER SYSTEMS via SSO below, or other authentication methods available in Lambda Learn in
For detailed steps, see Uploading Users With a CSV Text File under User Management.
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.
By default, the Self-Registration by email feature is disabled because of the possibility of spammers accessing your site.
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.
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
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.
When assigning a user another role in a context, use the Override feature in a specific context for exceptions.
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.
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.
The primary administrator (created when the site was created) cannot be removed from the site administrator role.
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:
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.
Deleting a User Account
Deleting a user account is a straight forward and easy process, but before you do so, you need to consider your organization's policy on retaining user data and their record of learning, such as: courses taken, completion and grade records, etc.
Deleting a user account deletes ALL their information from the system.
An account can be deleted by clicking the delete icon opposite the user's name.
When an account is deleted, the email address + timestamp for when the account was deleted is stored as the username.
If an account is deleted by mistake, it can be partially restored by resetting the deleted flag to zero in the database and resetting the username and email address. Grades may be recovered by re-enrolling the user into their courses and ticking the 'Recover user's old grades if possible' checkbox in the enrolment options.
Suspending a User Account
Suspending a user account does not delete any of their data. Users are just prevented from logging into and blocks any massaging from the system. The process of suspending a user is as follows:
- Click the edit icon opposite the user's name.
- On the user profile edit page tick the 'Suspended account' checkbox.
- Scroll to the bottom of the page and click the 'Update profile' button.
Disabling a User Account: "No login"
In the event you want to temporarily block a particular user from accessing your LMS, an administrator may "turn off" or disable a user's account by selecting "No Login" in the "Choose an authentication method setting" in that user's profile. This means the user will not be able to log into the site, but their account is otherwise unchanged.
When this setting is used, the email associated with this account may not be used to create another account.
Note: Users will not receive any error or other message when they try to log in but it simply will not allow them in. So it will appear as though their password was incorrect and they may attempt to reset it. Consider this issue when using No login, in order to reduce support issues.
The No login setting is in effect for the duration that the account is assigned to this authentication type.
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
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.
LOOKING FOR MORE?
Our eLearning industry experts have put together other resources to offer you more advice, best-practices, and how-to guides: