Details
Description
NOTE: For 4.1 this functionality is disabled by default, and can be enabled from Administer > CiviEvent > CiviEvent Component Settings. When enabled, cart style registration is used for ALL active events.
--------------
Make the registration interface allow for registering for multiple events with just one checkout.
This would be a sort of shopping cart where the user can add and remove events from the cart and then go through the checkout process where you can mix and match contacts for each event and then checkout and pay once.
We've implemented a version of this and attached a patch. It has some stuff that specific to the specific website we made the patch for, but we thought we'd release it just in case someone wants to give it a go.
This is a patch to CiviCRM 3.4.4.
Attachments
- cart-20120213.patch
- 256 kB
- Adam Wight
- mer.patch
- 44 kB
- Peter Haight
Issue Links
- is supplemented by
-
CRM-2474 Allow Selection of multiple Premiums
-
- Done/Fixed
-
Activity
This feature is being developed on a branch now:
http://svn.civicrm.org/civicrm/branches/v4.1.addtocart/
Current status is:
- Multiple events and participants can be checked-out at once
- Subevent selection screen when events exist with parent_event_id linked to an event in the cart
TODO:
- Document
- revert message templates and make sure we haven't changed template variable names
- cannot checkout with unpaid events in the cart
- hide the "conference slots" tab for now
- don't need the status message hack in civicrm.module
I made a big push on Monday, r37427... Here's the commit message,
- drop event custom field display, in favor of pre and post profile groups
- no default values are loaded
- input field hierarchy relying on array syntax should be researched
- handle unpaid events better
- delete cart participant immediately, using ajax
- check admin by permission, not by role
- use the session-stored contact email and name for all of the same contact_id, during checkout
- push participant form parsing down to the specific page
- begin to deprecate the EventInCart class
- event cart convenience methods
- require a fee level
- CRM_Event_BAO_Event::usesPriceSet instead of CRM_Price_BAO_Set::getFor. ??
- suppress default action (jump to top of page) when "delete" and "add" participant are clicked
- View Cart page "checkout" link is now a standard button
I'm maintaining a patch against civi 3.4 as well, throw a line if you think it's worth integrating.
Here are a couple of things that I noticed :
#1 I get this notice on Thankyou page of the cart checkout page when I register for 2 events with fee labels and make a payment
Notice: Undefined property: CRM_Event_Cart_Form_Checkout_Payment::$discounts in CRM_Event_Cart_Form_Checkout_Payment->emailReceipt() (line 333 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
#2 a)I get these notices on Payment page for the cart checkout when I register for 2 events one of which is configured with price sets and make a payment
- Notice: Undefined property: CRM_Event_Cart_Form_Checkout_ParticipantsAndPrices::$_values in CRM_Event_Cart_Form_Checkout_ParticipantsAndPrices->validate() (line 111 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/ParticipantsAndPrices.php).
- Notice: Undefined index: amount_priceset_level_radio in CRM_Event_Cart_Form_Checkout_Payment->process_event_line_item() (line 176 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
- Warning: array_keys() expects parameter 1 to be array, null given in CRM_Event_Cart_Form_Checkout_Payment->process_event_line_item() (line 176 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
- Warning: end() expects parameter 1 to be array, null given in CRM_Event_Cart_Form_Checkout_Payment->process_event_line_item() (line 176 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
b) and following on the Thank you page :
- Notice: Undefined index: amount_priceset_level_radio in CRM_Event_Cart_Form_Checkout_Payment->process_event_line_item() (line 176 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
- Warning: array_keys() expects parameter 1 to be array, null given in CRM_Event_Cart_Form_Checkout_Payment->process_event_line_item() (line 176 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
- Warning: end() expects parameter 1 to be array, null given in CRM_Event_Cart_Form_Checkout_Payment->process_event_line_item() (line 176 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
- Notice: Undefined property: CRM_Event_Cart_Form_Checkout_Payment::$discounts in CRM_Event_Cart_Form_Checkout_Payment->emailReceipt() (line 333 of /home/yashodha/svn/trunk/CRM/Event/Cart/Form/Checkout/Payment.php).
#3 The labels /display of items (the section in which we list events, participants, price, etc ) on Thank You page and HTML recept version doesn't match the one on the text email receipts.
#4 Event location is missing in the TEXT version.
#5 The order of billing info / credit card info needs to be fixed for the text version so that it is in sync with HTML version and ThankYou page.
Cart Review - 11/28 - results for simplest use cases are below. I'll test price sets and profiles next - but would probably be good to straighten these out first. Ping me with any questions etc.
==================
I. Logged in user, no profiles, simple event fees using the 2 sample events, dummy processor, same participant for both events.
Cart Checkout (civicrm/event/cart_checkout) - Regular fees (not price set)
----------------------
1. Use specified Fee Label as label for radio buttons (civicrm_event.fee_label) instead of hard-coded string "Price Levels"
2. Set the specified default fee level (i.e. radio button s/b checked) - (civicrm_event.default_fee_id)
3. Probably should remove hard-coded First Name / Last Name fields. These can be included in the Profile if site admin wants to collect them. (unless we wind up pulling out Profile support)
4. Need to set defaults for email address and profile fields if user is logged in OR if checksum authentication has been invoked (i.e. we have a known contact id).
Cart Checkout step 2 (Payment.php - credit card and billing fields)
------------------------
1. I don't understand the purpose of this formRule on the billing email: "Billing contact email does not appear to belong to a valid user." It looks like you're checking if there's an existing contact w/ this email - but given that anonymous users can register they might not exist yet in DB (or they might not have used this billing email yet). What was the rationale for this check?
2. Set defaults for logged in / authenticated user - pre-filling billing first, middle, last name as well as email and address if contact has an email record / address record w/ location_type = Billing.
Cart Checkout step 3 (ThankYou.php - thank-you page)
---------------------------------------------
1. Fix notices
- Notice: Undefined property: CRM_Event_Cart_Form_Checkout_Payment::$discounts in CRM_Event_Cart_Form_Checkout_Payment->emailReceipt() (line 333 of /Users/dgg/svn/crm_v4.1/CRM/Event/Cart/Form/Checkout/Payment.php).
2. Post-process Bugs
2.1 contribution.source should be 'Online Event Registration:' . $eventTitle
2.2 Billing address / billing email fields from Payment.php are not being saved to the DB
2.3 First and Last name from ParticipantsAndPrices form also not being saved to DB
2.3 contribution.address_id should be set to billing address record id (once 2.2 is fixed)
2.4 participant.fee_level column is not being set (should save the label of selected event fee level here) - e.g 'Super Stars (ages 13-18)'
2.5 Two activity records (type = Event Registration) are properly inserted, but the subject says "Fall Fundraiser Dinner - May 28th, 2012 5:00 PM - Attendee - Pending in cart" even though I've completed checkout and paid.
===========
II. Anonymous user, 2 events, no profiles, dummy processor
1. This flow doesn't appear to be supported, Checkout button redirects to /user if I'm not logged in. Also, I don't see the status message unless I visit a civicrm URL (i.e after I log in I see this message above the Checkout form: "You must log in or create an account to register for events." - which is confusing because I just logged in ).
Hopefully you can fix things so that anonymous users can use cart checkout. If not, you'll need to minimally fix things so that the above status displays on the Drupal user login form. You can use CRM_Utils_System::setUFMessage() for this.
===========
III. Logged in user, no profiles, simple event fees using the 2 sample events, dummy processor, different participant for each event. Logged in user is doing the registering, and registered for 1st event in cart. Entered new name and email address for 2nd event participant 1.
1. Logged in user registration is ok (other than bugs in flow I. above). Second participant Name shows up as expected on ThankYou page - but an EMPTY contact record is created (in the trash) for that participant (no name or email data, is_deleted = 1). The participant record for this person is properly keyed to that empty deleted contact record.
Event Cart Review = 1/3/2012 (4.1 b1)
==============================
I tested logged in and anonymous user checkouts with a few common "features" (registration profile, participant custom field, ...). The authenticated user registration scenario still has the "known issues" listed on the wiki page but is "usable". The anonymous scenario seems quite broken still.
1. Logged in user registration test
- Rainforest Tournament event is configured with a Profile containing first name, last name, a contact reference custom field (extends Individual), and a radio button custom field (extends Participant)
- Fall Fundraiser registration config not modified from sample data
- Dummy payment processor assigned to both events
- put both events in cart and checked out
Results:
- Billing address is being saved now. However, on a subsequent test the existing billing address is not being loaded back as default values in the Billing Name and Address form fields during checkout.
- Participant custom field included in the registration profile shows up on checkout form, but values aren't being saved to the DB
- Contact reference autocomplete widget is broken. Inspected with Firebug and the dynamic URL in the associated <script> is empty (might be other issues as well). Whatever is causing this might also be affecting other custom field widgets (esp date picker).
- other known bugs (as listed here: http://wiki.civicrm.org/confluence/display/CRMDOC41/CiviEvent+Cart+Checkout) are still present.
2. Anonymous user registration test:
- Rainforest Tournament event is configured with a Profile containing first name, last name, contact custom field and a participant custom field
- Fall Fundraiser registration config not modified from sample data
- Dummy payment processor assigned to both events
- put both events in cart
- entered 2 different participant emails - 1 for each event
- entered a billing email same as participant email for 2nd event
Expected Results:
2 new contact records
1 participant record linked to each participant
2 contribution records linked to contact record of participant 2 (since his email was the billing email)
Actual results:
9 new contact records, 8 of them are "in the trash"
2 participant records linked to each of 2 deleted contact records (participant 1 and participant 2 email addresses used in these records)
1 other of the deleted contacts has the 1st and last name from the profile (this should be participant for event 1 but this record has no participant record linked to it
2 contribution records are linked to the one "not deleted" contact (which has the billing email and billing address linked to it)
Adam, I'm definitely interested in the patch against the 3.4 branch, as well. The "mer.patch" attachment listed here doesn't create any of the new files referenced within that patch, so I'm unable to test anything.
The code is running in several production sites (in 3.4.7). Adam will submit a patch to fix the outstanding bugs against 4.2 (trunk) in the next month.
Les, the new attachment "cart-20120213.patch" is a git diff of our changes to CiviCRM 3.4.7, please let me know if this gets you started. There are a few other, unrelated fixes rolled into that patch, sorry I can't isolate at this point.
I see this is integrated with the release of 4.1. Thank you for your contribution.
Have 2 pressing questions on a current project that would highly appreciate comments on.
1) Why by default are there 2 email addresses listed with each participant? Is this the default profile?
2) Is the billing information, name, address, email, etc. associated with each participant? Is it stored in the database and associated with the participant?
When I view the participant I am not seeing this information. I'll need to be able to send an email to the billing contact when the user completes an event registration.
I figured out my own answer to my 1st question. The profile was the issue. Still wondering whether how the billing data can be accessed in the db?
Hi Jeff,
This is exactly the case our clients want, it's working in their production environments, but I can believe that support is broken in civi trunk.
The billing data should be provided by the customer in the last step of checkout, and billing name, email and address will be saved to the billing location of the contact specified by the "Billing Email Address". Please try to reproduce your bug on the civicrm sandbox, by logging in and entering the URL /civicrm/event/add_to_cart?id=3, and I'll see if I can integrate any changes we have on our side.
Thanks.
Adam
Hi Adam, tested this on the sandbox with the Rainforest event. When I enter the billing information on checkout it does not look like it gets stored anywhere. When you view the event participant records for that event there seems to be no indicator or association with the billing information. I desperately need the ability to generate followup emails to the billing party. I know that the simple receipt sends a invoice to the billing party but it does not seem to store this information anywhere. If there is anyway possible you could put something together to resolve this I would highly appreciate it. If it needs to be sponsored I'd like to help.
This feature was merged with trunk. New bugs should be filed separately.
A few more fixes were commited in r39769
I suspect we'll need to do this as an MIH to integrate it into civi core. The issue is a good start for us to send folks to who are interested