Upgrade the cod_events Feature to D7

This is the first go at it. It's basically a straight port from 6.

Related issue: #849066: Better support for free events.

Oks.

I found a few things to i think needs to be discuss:

1. Profile module in drupal 7 is marked as deprecated and this module is part of the dependencies of cod_base feature, i think to could be more convenient use profile2, and recreate the profile fields using this new module.
2. Seems to there is a bug into the integration with signup and bulk view operations, i'm going to take a look more in deep on this for provide a patch for this into the signup module.

And it's all, without these two things i can provide now the first version of events free feature.

I attached the patch

Does there actually need to be two different content types, one for free and one for paid events? Is it plausible to just have a single event content type tied to registration and an additional module say cod_paid_signup that ties in commerce_registration? Basically free by default with optional support for paid.

I suggest defaulting to free events and having the ability to use the same content type for paid events. That way, we can simplify configuration of content types by making it easier for paid and free events to share fields.

Have there been any architectures written up for how everything would be laid out with commerce & registration? I've done some issue searching but have not found anything.

The most extensive work exploring this has happened at http://drupal.org/project/commerce_registration.

Thanks for taking a stab at this!

@brent - Sure, I will email you my skype. I'm actually doing all of this to decide if I'm going to role cod7 for our camp two months before yours. Will shoot you an email now.

Here is an updated patch that includes free event registration support via the registration module. It is actually quite slick and I think the commerce part should come together fairly fast. So this patch will:

• Removes all references to signup module
• Removes all references to ubercart module
• Removes the install hook for ubercart event product class creation
• Adds a generic event content type with same fields date and image
• Removes the view of signups from old signup module
• Adds a dependency to the registration module
• Adds a registration field to the event content type
• Adds a "Free Event" registration type

I really like the registration module. It lets you define registration types and in our case I assume we would have a "Free Event" and "Paid Event" types. When you create an event node, you then select which kind of registration this is.

I am now going to see the status of commerce_registration. I believe what is going to happen is I'm adding a product reference to my Event content type, and then the rest is magic. If I'm creating a paid event, I would select that as the registration type and select the event product. If I wanted a free, then I select free type and no product. I will test and add an updated patch if it all works.

Ok I think this is my last patch for the day. This is more of a proof of concept patch at this point. This patch will:

• Remove references to Signup & Ubercart module
• Remove the install hook for ubercart event product class creation
• Add a generic event content type with original fields: Date and Image
• Removes the view of signups from old signup module dependency
• Add a dependency to the registration, commerce, commerce_features and commerce_registration modules
• Add a registration field to the event content type
• Add a product reference field to the event content type
• Add a "Free Event" and "Paid Event" registration type
• Add a "Paid Product" commerce product type with a field "Registration" type defaulted to paid registration

I am using the latest dev of registration and commerce_registration and had to apply the following patch:
http://drupal.org/files/1483136.20-commerce_registration-fix_validation....
from issue #1483136: Fatal error: Call to undefined function

This patch provides two workflows:
Free Events

• Create a new event node and select "Free Event" under Registration
• Ignore the product field

Paid Events

• Create a "Paid Event" product and select "Paid Event" under Registration field on the product entity
• Create a Event node and DO NOT select a registration value, but do select the event product

Free registration is a snap, just register and poof its done. Paid registration was just as easy. After add to cart and I filled out my billing information, I then filled out the registration form and completed the payment and was registered. For the node creation, on my personal sites I would likely create a checkbox of some sort to pick if its a paid registration or not and then hide show the registration/product field accordingly with conditional fields. That is just eye candy. Proper descriptions and documentation and its fine as it is.

Again this is more of a proof of concept. In all likely hood, all the of the product types and fields would be in their own feature that depended on cod_events so a user wouldn't need commerce turned on even if they were not using it.

I think the next step is:

• Get people to test this out
• Create a separate feature for the paid stuff
• Check on statuses of registration
• Create some custom views for people whom are registered if we don't like the default that comes with registration

Hi mrconnerton - Thanks for rolling this patch! I agree with your list of next steps. I started with

Get people to test this out

;)

This patch is a great start.

Below are some issues I encountered testing the free and paid registration workflows. These likely would be addressed individually in Commerce_registration, Registration, COD_events and Commerce modules. They all come together to provide one workflow and UX so I'm listing them together here so that we can understand them as a whole and break them out into issues in their respective projects.

Free workflow:

The event node shows "This registration is for:" even after I've registered. I would expect it to show a confirmation that I've registered as the most important information, possibly with the ability to add other registrants if necessary as a secondary option.

Paid workflow:

- I am prompted for billing information before entering attendee information. It seems like #1500132: Allow reverse workflow of register to checkout instead of just checkout to register is the issue that's focused on reversing this order.

- After entering billing information, I'm automatically sent to the next step while still inputting my zipcode.

- The next screen has a fieldset inside of a fieldset and asks who registration is for, with choices of "myself" "Other user" and "Other account".

This strikes me as putting too much burden on the user who is checking out to know which users already have accounts and which ones do not, or having to search for account objects to figure that out.

I suggest we borrow from the UC_Signup checkout workflow which first prompts the user who is checking out for a list of email addresses for each event, and then detects who already has an account. This workflow was validated with usability testing as well as orders on sites with up to ~30ish attendees registered in a single order.

- For attendees that didn't already have an account where I entered an email address, I was not prompted to create an account. COD assumes that everyone who is registered will have a user account on the site.

- Clicking the "Add to cart" button didn't give me any visual confirmation that the event product was added to the cart, nor did it redirect me to the cart.

- I was never shown a registration #/confirmation. In D6 COD, UC_Signup adds a signup ID number to the order.

This is a great start and the result of contributions by the ThinkShout folks, jpontani, mrconnerton and others.

Thanks, everyone!