Forum .LRN Q&A: Paying for classes
Do any of the ecommerce experts have thoughts on how it should be done?
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.
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.
- 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.
- 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.
- 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
- Group classes by department and subject
Please comment on how you think these connections should be implemented.
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.
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
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.
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 ?
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.
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.
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.