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.
