Ubercart

Hey Greg, thanks for popping in with the questions. I'm actually excited about the opportunity for Ubercart to handle event sales in the future, and I'm definitely interested in any feedback this project of yours might generate.

I think I'll limit my response to just straight answers to your questions followed by a bit of brainstorming...

1) To gather custom CiviCRM data on checkout, ideally you could do so through a custom checkout pane. I have a small demo contrib up here on Ubercart.org called Lead Tracker that shows how you can store data from a custom checkout pane in the $order->data array during checkout. Your module could then move that data into CiviCRM when the order is completed or something. I personally am moving more and more toward working through CA actions, because it's easier to do things like perform an export on the customer completes checkout trigger.

2) For that, I don't think there's much precedent. If you need it stored per product, you can alter a select list onto the add to cart form and store that data using hook_add_to_cart_data(), but there may be a better way...

3) For choosing the day, I'm not sure how I'd handle it. I think using an attribute would be fine, but you'd want to make sure to use separate SKUs for reports generation. In other words, in my mind, each day the whole class is offered represents a different product, even if we see it as the same class. If you want a product report to show which days are more popular, then you'd want the SKUs to be different based on the day chosen, which you can do through the Adjustments tab. If this is too cumbersome for the site maintainers long term, then you might just consider each "section" of a class having its own product.

4) I don't think I'd use a product kit. If any 3 sessions represent one whole course, I think I'd instead do something like make a textfield attribute and use hook_form_alter() to turn that into something that appears to the user like a widget for selecting days but stores their selections in plaintext. I'm not sure how this would work for all your products, but it's a thought. The product kit would require you to list each day as a separate product, but imo if 3 days are required for purchase, then it's a group of 3 days that are a product. This should also help on reports, too.

5) That's the toughie. You'd need to create a custom report for this, really.

So, one thought re: 2 and 5 is you might have a use case here for UC Node Checkout. The idea behind that module is when someone goes to purchase a product, they get sent to a node add form of your choosing. This is how I handled registrations for the DIWD site, and the module's been improved since then. As of the latest development (in 6--2-beta) for D6, that module allows you to create a View and associate any product in that View with a node type. The latest dev also lets you specify the product's attributes on the node add form. So, the workflow is something like...

1. You create a registration node type that contains common elements for all your classes. Re: #2 above, this might include the "how did you hear about this course" element. I also disassociated purchasing registration from the user account, so you could register other people for DIWD through a single account. To do this I made the title the last name and added a first name field.

2. Someone who wants to register either finds the course they want and clicks "Add to cart" and gets redirected to the node add form or navigates to node/add/registration, chooses the course from the View populated select list, and is redirected to the node add form. When they submit the node form, the product will be added to the cart. They can even update existing products in the cart.

3. They complete checkout.

4. You'd need a custom module that could operate on all the nodes associated with the order. On DIWD, I defined a custom Wf-ng action that would loop through all the products, look for a node_checkout_nid in each product's data array, and update the node if it found one. I had a hidden field on the registration nodes that contained a link to the order, for example. I would populate this field once someone checked out. Administrators could then easily navigate to the associated order w/ someone's registration.

5. You can create a custom View that the site's administrators could use to view lists of who was registered for which course. This is the big win for #5 above...

So... that's like a buffet for thought. Hope it helps.

some days ago I saw a page. I don't remember how I reached that page... about a site selling events

Just Racing UK - Selling an Event with Drupal, Ubercart, Views, Dates and some glue
http://yopensource.com/en/news/drupal-news-and-announcements/369-just-ra...

UPDATE:

I have decided to use uc_node_checkout.

I've created the following cck content types:
* course_description (basic cck content type)
* course_session (product class)
* course_registration (uc_node_checkout)

course sessions nodes have a node reference to course description nodes. The course description describes the course and is fairly static, but each term a new course session is created. I used two date fields, a date repeating and a date multi select to deal with various scheduling options.

When a user adds a course session to their cart, they create a course registration where they add some data like "How did you hear about this course?"

This handles 90% of the courses.

The last scenario that i still working on is a course that has 5 meeting days and a user needs to signup for 3.

I am planning on either using a product kit, or creating a second uc_node_checkout course_registration_multi content type that applies to a different course_session_multi content type. The difference would be an added field that asks the user to select the sessions the plan to attend. I would "generalize" the session data so that in the course_session_multi content type there would be 5 date fields called "Meeting 1" "Meeting 2" etc... and on the course_registration_multi there would be a multi select or multiple value field that would correspond allowing the user to select which meetings the user was going to attend. I don't really like this solution because it may be too rigid not allowing for a course that has 10 meeting days that a user needs to select 8 of, for example.

I need to do more research into the product kit.

Another option is to use attributes that are text field attributes where the user must enter the actual meeting days, i could have 3 such attributes, but again, this is rigid, using attributes with pre determined values also does not work for a variety of reasons.