We're new to Moodle, so I'm looking for any pointers to specific features we might could use.
We will be selling access to individual courses. Some will be one user purchases one course, which seems fairly common.
However, we also will sell "bundled uses" to a course. In other words, an individual may buy a course they intend for a number of other users to take (say, 100 users). Those 100 users may not be known at the time of purchase.
What is the best way to handle this? I'm not necessarily looking for a fully automated solution, but any features we could use to help with this (like, say, manually creating one user account who could create X number of users in one course).
Thanks for any advise.
I've thought about this before, and indeed thought about it just yesterday too.
My preferred solution would be to hand out 100 one-time enrolment keys which, when used, cannot be used again. Sadly this feature doesn't currently exist in Moodle but there are a number of different solutions on the Tracker: MDL-15448 and MDL-2448.
(I know it's not a solution but the more votes on the tracker these issues get, the more seriously they will be taken and possibly implemented.)
Paul.
My preferred solution would be to hand out 100 one-time enrolment keys which, when used, cannot be used again. Sadly this feature doesn't currently exist in Moodle but there are a number of different solutions on the Tracker: MDL-15448 and MDL-2448.
(I know it's not a solution but the more votes on the tracker these issues get, the more seriously they will be taken and possibly implemented.)
Paul.
Yes, those would be nice features. I had looked a little at the enrollment key feature, but it seems rather limited, at least for what I'm trying to do.
Perhaps one day...
Perhaps one day...
Looks really interesting the moocash thing but when I go to the source forge there don't seem to be any file for download . . . 
Hi,
Thanks for you interest! You can grab the stable or development versions with Subversion or I can get you a tarball if that works better for you (the SF Code tools will also let you download a tar archive if you are browsing the source).
Here's the readme:
https://sourceforge.net/apps/trac/moocart/browser/trunk/moocash/doc/README_FOR_APP
A command like this will work for development trunk:
svn co https://moocart.svn.sourceforge.net/svnroot/moocart/trunk/moocash moocash
for the stable milestone:
svn co https://moocart.svn.sourceforge.net/svnroot/moocart/branches_fillin_membernumbers moocash
Feel free to contact me directly with any questions.
hth,
adric
Hi,
Sorry about that. I've added an archive of the stable milestone (fillin_membernumbers) to SF and you should be able to download it now.
Please let me know if I can answer any other questions.
Thanks,
adric
Sorry about that. I've added an archive of the stable milestone (fillin_membernumbers) to SF and you should be able to download it now.
Please let me know if I can answer any other questions.
Thanks,
adric
Hi,
At our org we have a shopping cart package that handles all of the money, and some backend code that then creates Moodle users and enrollments from that. For our model the customer might not be the student, and so we create the Moodle user based on the shipping address, rather than the billing address. Of course this gets messed up and has to be straightened out by (calling/emailing) customer service. We have a soft policy that a group purchase should just be handled directly by customer service so they can figure out which accounts get what name and what enrollment.
We use ZenCart for the commerce site and the database scripts that sync things up from Zencart to Moodle are called MooCash. MooCash is freely available as part of the MooCart project over at moocart.sf.net.
Hope that helps!
adric
At our org we have a shopping cart package that handles all of the money, and some backend code that then creates Moodle users and enrollments from that. For our model the customer might not be the student, and so we create the Moodle user based on the shipping address, rather than the billing address. Of course this gets messed up and has to be straightened out by (calling/emailing) customer service. We have a soft policy that a group purchase should just be handled directly by customer service so they can figure out which accounts get what name and what enrollment.
We use ZenCart for the commerce site and the database scripts that sync things up from Zencart to Moodle are called MooCash. MooCash is freely available as part of the MooCart project over at moocart.sf.net.
Hope that helps!
adric
Thanks! Do you know of anything similar for Miva Merchant? Eventually, that will be our shopping cart (it's another ongoing project here).
Still, I assume you are always selling one use for one user? Meaning, you don't have any one user that buys uses that they want for a group of people?
At present, we will be handling purchases manually (they pay us, we set them up an account). But that doesn't handle this "bundling", unless we have them pay us then call us every time they want to add someone for one of their paid bundles (which is an administrative headache we're hoping to avoid).
I've been looking at the "external database" enrollment plugin. Could that be used here?
I was thinking I could write a small web application where we would create a "master" user, and give them access to that web application. The application would need to track which course and how many uses, and allow the master user to add up to that many uses to an "enrollment" table. Then the end user could self register and automatically be enrolled in that course.
Could something like this work? Is there anything I'm missing?
Hi there
Although a commercial service - Course Merchant would allow you to do this (www.coursemerchant.com)
All the best
Richard
Although a commercial service - Course Merchant would allow you to do this (www.coursemerchant.com)
All the best
Richard