Forum .LRN Q&A: Paying for classes

Collapse
1: Paying for classes
Posted by Caroline Meeks on 10/10/03 12:31 AM
Has anyone worked on integrating dotLRN with ecommerce yet to allow online registration with payment?

Do any of the ecommerce experts have thoughts on how it should be done?

Thanks

Collapse
2: Re: Paying for classes (response to 1)
Posted by Jun Yamog on 10/10/03 09:58 AM
Not sure about .LRN but I think it can be done.

http://www.semizone.com/catalog/

This is done using e-commerce of 3.4.11.  So I guess products = courses.  Well roughly.  Then change the terms to be more education like.  Also since it is basically granting access, no product delivered.  On 3.4.11 it was like auto shipped or something like that.  So you already charge and do the processing after the checkout.

Collapse
3: Re: Paying for classes (response to 1)
Posted by Deds Castillo on 10/10/03 10:11 AM
Jun is right.  You treat the registration as products.  Though for Semizone.com, Jun modified a lot of code for the interface code and I modified finalize-order to bypass shipping stuff plus other site specific requirements.  But, yes, it is workable using the existing ecommerce package.
Collapse
4: Re: Paying for classes (response to 1)
Posted by Jun Yamog on 10/10/03 10:26 AM
Deds,

You make it sound as if we knew what we where doing :)  I think it was more like.  I got a notebook, and tcl book.  And trying to figure out what the heck are all this "[" "]" for.  And all this select this and that.  Hehehehe.

Sorry Caroline... getting off the topic.

Collapse
5: Re: Paying for classes (response to 3)
Posted by Caroline Meeks on 10/16/03 02:28 AM
I'm following your advice and setting up ecommerce first. We may even launch with just ecommerce. Looking ahead I see that ecommerce and dotLRN will have to communicate in a few places.
  1. Group Membership
    • When a user buys a class they need to be granted class membership.
    • When a user "returns" a class they need to have membership revoked.
  2. When you create a class you need to optionally also create one or more products.
    • Use Case for multiple products: Class is offered at different prices for credit or audit.
  3. Displaying available classes
    • Group classes by department and subject
      • Right now I am using categories to create a UI that looks like this, but eventually it should directly reflect the dotLRN hierarchy
    • Check for availability for a specific user
      • Check capacity (waiting lists? integrate with events?)
      • Check for prereqs
      • Check for appropriate registration status
      • Check for scheduling conflicts
This is my start on a big picture requirements. I don't know how much of this I will end up coding for this current project.

Please comment on how you think these connections should be implemented.

Thanks!

Collapse
6: Re: Paying for classes (response to 1)
Posted by Dave Bauer on 10/16/03 02:34 AM
Hmmm.

This seems like a job for acs-service-contract.

There are at least two ways to go about it:

1) When a new class is created, create a product to go with it.

2) When a new product is created, create a class to go with it.

It might be nice to allow both situations.

Collapse
7: Re: Paying for classes (response to 6)
Posted by Carl Robert Blesius on 10/16/03 02:43 AM
That would be an interesting way to integrate events into .LRN too.

New event -> create a product to go with it
New class -> create and event to go with it
New product -> create a class to go with it

Collapse
8: Re: Paying for classes (response to 7)
Posted by Alfred Werner on 10/16/03 02:59 AM
Some people like to charge per access to files / like for research reports - so in file-storage

New file -> create a product to go with it. (Maybe folders have an free/fee attribute?)

Shows that we need to keep our minds open to the possibilities.

Collapse
9: Re: Paying for classes (response to 6)
Posted by Malte Sussdorff on 10/16/03 05:47 AM
I would favour the way of adding the object first before making it a product (instead of first having a product and then getting the object). Reason is that I forsee the possibility to write one standard way of adding a product to the ecommerce installation. Taking the /o approach, you could then link to the "product" directly.

But how would you link permissions with paid items. I could imagine, if your service contract for creating the product stores the object_id you can easily create a permission record of read. Though, would this be enough? Or do we need to define, what permission will be given to a certain object once the product has been paid? And if so, how do you do this. Should there be a link e.g. in the class administration that says "make it a product", linking to a page that enables you to give some description for the product and the permissions that will be granted on the class (or file, or survey or whatever we might come up with).

Last but not least, how much more work would a general approach be vs. a specific one just interfacing classes and e-commerce. And would you be willing to go down that extra mile Caroline ?

Collapse
10: Re: Paying for classes (response to 5)
Posted by Bart Teeuwisse on 10/16/03 05:50 AM
Caroline,

you'll have to write custom code which hooks into the ecommerce package to achieve #1.

For #2 you could use the ecommerce classes. Within ecommerce you can define your own user classes and each class can have a different price for a product. Custom code would place a student in the appropriate class. If the price is not dependent on the type of student then I see no other option but to create 2 different products. One for credit and another for audit.

Be aware that ecommece only supports 3 levels of categories and not any deeper. The limitation is in the data model rewriting will be rather involved.

Ecommerce doesn't keep track of inventory which means no head start to build avialability with.

/Bart

Collapse
11: Re: Paying for classes (response to 1)
Posted by Alfred Werner on 10/16/03 06:56 AM
One other thing I've had clients ask for is the ability to have sites be fee based - to access certain areas for example you might have silver/gold/platinum members. A typical complication is that pricing of hard goods (related materials typically) is tied to member level. E-commerce has, if I remember - user classes. So when someone joins, they would not only need to be put in the right group in the regular hierarchy, but also in the corresponding user class for e-commerce. In a school context, you might have similar for full-time/part-time, in-state, out of state, etc.
Collapse
12: Re: Paying for classes (response to 1)
Posted by Brad Duell on 10/16/03 05:53 PM
For #1, currently, we've dropped two of the user class tables that ecommerce uses, and created views on the actual groups in openacs with the same names:

create or replace view ec_user_classes (user_class_id,user_class_name,last_modified,last_modifying_user,modified_ip_address) as select group_id as user_class_id, group_name as user_class_name, sysdate as last_modified, 0 as last_modifying_user, '0.0.0.0' as modified_ip_address from groups

create or replace view ec_user_class_user_map (user_id,user_class_id,user_class_approved_p,last_modified,last_modifying_user,modified_ip_address) as select person_id as user_id, group_id as user_class_id, 't' as user_class_approved_p, sysdate as last_modified, 0 as last_modifying_user, '0.0.0.0' as modified_ip_address from persons, groups where acs_group.member_p(person_id,group_id, 't')='t'

This means dropping fk constraints on ec_product_user_class_prices, ec_product_recommendations, and ec_spam_log

For #2, we're working on a product-gateway (which acts much like the payment gateway, but, obviously, for products), which will allow us to easier sell material goods, and services like classes and workshops without having to register them as products in the ecommerce package or having to manipulate the table names as views that the ecommerce package uses (basically any object in the system).

We'd like to finish this product-gateway implementation by December.

Collapse
13: Re: Paying for classes (response to 1)
Posted by Caroline Meeks on 09/09/05 04:41 PM
As an update to this thread.

This work has now been done in the dotlrn-ecommerce package that is in CVS. We are about to launch our first clients and we will provide more details and documentation in the coming weeks.

Collapse
14: Re: Paying for classes (response to 1)
Posted by Rafael Calvo on 09/10/05 12:21 AM
Caroline
That is great news and needs to advertised more. Could you write a paragraph foro the news section here and in dotlrn.org?

thanks

Rafael