Demystifying Moodle Authentications, Enrollments, and Payments: How a small business can sell Moodle courses…

Listen with webreader

…without hours of tedious labor, undo hardship on the client, or risking exposure to spammers.

There seems to be a lot of confusion over enrollment, authentication, accounts, payments, roles, and permissions in Moodle.  Sometimes it’s best not to think too hard on things like this…and once you have a basic grasp of the concepts, employ the methods that make it easiest on both you and your students (paying clients). 

Authentication ≈ Account Creation

User accounts are authenticated before being allowed to log in to a Moodle site.  Each account is associated with a single user (not a company or department), with one username, one email address, a password, and other defining characteristics, which are all contained in the profile

One Person = One Account = One Profile

A Moodle site has one place where users are listed and maintained.  Let’s call it the guest list.  On second thought, let’s not, since “guest” has a different meaning in Moodle.  Let’s call it the membership list at a health club or resort.  This list applies to the entire site

User accounts can be created using any number of authentication methods.  They include email-based self-registration (totally automated), manually (where the administrator creates the accounts, either one at a time or by uploading a file), or by external databases that feed information to the Moodle site.  Any one Moodle site can have multiple methods active at the same time. These methods are very good at keeping fake people (spammers) from flooding your site with junk.

Bigger companies often have internal authentication methods (on their non-Moodle servers) which work very smoothly with existing Moodle authentication methods.  If you run a small business, you aren’t likely to have such a ready-to-use feature. There is a recent release for a WordPress integration with Moodle for just this purpose.  I haven’t tried it (yet) but it sounds like it would be awesome for small business users.  

No one can do anything (like take a quiz or post to a forum) without an account.  Guests are sometimes allowed to do some things.

Roles and Permissions

A Moodle site has several sections that reside in two general areas: the front page and the courses.  Think of your Moodle site as a hotel, an exclusive resort, or even a health club.  You could even imagine it as a university campus!  When a user shows up at the “Moodle front door”, the door man (which is the user database) checks to see what permissions this person has.  Some people are allowed to go everywhere…into the kitchen, behind the front desk, into the offices, into the storage room, and into all classrooms.  They are allowed to move the furniture, close off room, let people in, and turn other people away.  These people are typically called administrators

Others who show up are allowed to view the facilities from a distance; maybe they never make it onto the grounds.  They might be given a guided tour of the main lobby area; maybe they are allowed to take one free class.  Their access is very limited, and they are known as guests

There are several other types of users, with more privileges than a guest, but less access than an administrator. 

The thing that controls who gets to do what in Moodle is known as permissions, which are associated with roles.  There are standard Moodle roles (admin, teacher, non-editing teacher, etc.) and default permissions for those roles.  These defaults are so logical that I rarely change them; actually, I never do.  Once in a blue moon, I add a new role, with custom permissions. 

Where I control access is through the content itself.  I set courses to allow guests, allow users to enroll themselves, be free, cost money, or not be visible at all to anyone but me.  I usually leave all the rest of the content (associated with the front page) open to everyone, but on occasion, I allow only authenticated (logged in) users to see it.  The one example where I do this all the time is with the Theme Switcher block.  I let people who are logged in play with the theme, but not just anyone who walks in from Google. 

Enrollments and Payments 

Once a user is authenticated, it gets him in the front door.  He doesn’t necessarily have a space in a class or a room at the resort.  With the exception of administrator, users’ roles don’t allow them access to courses.  That is where enrollments come in. 

While authentication (log in) is on a site-wide basis, enrollment is by course.  (Roles can be site-wide or by course because nothing is ever simple). Enrollments can be accomplished by the user himself or by an automated method using one of the aforementioned external database integrations. 

For a user to enroll in a course himself, he needs to make a payment (via PayPal, Authorize.net, Course Merchant, etc.), or enter an enrollment key, but not both.  Either will work, depending upon how the course is set up.  (Users may also be enrolled by the administrator in much the same manner as manually creating accounts).  

As Yogi Berra might say: Enrollment Keys are as Good as Money

Enrollment in one course does not enroll the person in other courses.  (Except for meta courses, which we’ll talk about another time!). 

Enrollment in a course gives a user the role of student in that one course.

Additional roles (such as “teacher”) may be assigned to a user within the course, using the assign roles function.

How all these come together so you can make money selling your awesome Moodle courses

Authentication and Enrollments work together in a number of ways to provide access to your Moodle course content.  Following are some common scenarios that might apply to a small business offering Moodle courses for sale: 

  1. Sally pays you (the Moodle site owner) directly.  She does this with a check, PayPal, cash, or this nifty WordPress/PayPal button.  You manually create an account for her (authenticate her as a user) and manually enroll her in the course(s) that she paid for.
  2. Sally pays you.  You tell her to create her own account (email-based authentication) and give her an enrollment key for the course(s).  She logs in, enters the key, and is enrolled into the course.
  3. Sally pays you.  You tell her to create her own account (email-based authentication) and you manually enroll her in the course.
  4. Joe goes to your Moodle site, creates his own account (email-based authentication), and enrolls himself in the course by clicking on the PayPal button (or other payment method you have installed) associated with the course at the Moodle site.  You never even talk to Joe.
  5. You create an account for Joe and tell him to go shopping!  He buys as many courses as he desires by paying for each one directly through Moodle.  This might be the situation when you have a members only Moodle site, allowing users who belong to some organization and/or have paid a membership fee.
  6. Your client wants to enroll 30 people.  You have a purchase order for the entire amount.  You invoice your client and upload a CSV file with all 30 names into your Moodle installation.  In one fell-swoop, you create 30 accounts and enroll all 30 people into one or more courses.  

To offer discounts, varying course charges, or multiple course enrollment with one payment, you will need to employ a service such as Course Merchant, discussed in a previous post.  Whew!  Did you get all that?

Share

Tags: , , , , , , , , , , , , ,

Leave a Reply

You must be logged in to post a comment.

  • LinkedIn LinkedIn Facebook LinkedIn newsletters
  • Archived Posts
  • Archived Newsletters
  • Sign up for Albany Analytical Newsletters
    * = required field
    I would like to receive the following newsletters:


  • Test

    Testing Sidebar 2

© 2010, All rights reserved, Albany Analytical, Inc.

Blossom Theme by RoseCityGardens.com

/***Google Analytics Code ***/ /***End of Google Analytics Code ***/