Upgrade the cod_events Feature to D7

Didn't wind up getting started! Unassigning.

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

Thanks for this patch.

Since we're switching to Drupal Commerce, we should remove all the Ubercart components here, including the old drupal_execute code that was in place before Ubercart product classes had exportables.

One limitation of Ubercart that affects the Drupal 6 version of COD is that the uc_product module must be the owner for product content types, which makes it difficult to separate the functionality for paid and free events sharing a single product/content type between 2 feature modules, such as a cod_events_paid and cod_events_free.

My understanding of Drupal Commerce is that it removes this limitation, and that we can now split out this functionality so that sites that don't need ecommerce functionality don't have to enable DrupalCommerce.

Since the major work involved in adding support for paid events is writing a Commerce-oriented equivalent for UC_Signup , it probably makes sense for us to start with a cod_events_free feature for COD.

Luckily, this is relatively easy to do - thanks for starting that work :).

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

I want to help to migrate COD to D7 so, i already read the state until now and i think to i'm ready to help.

Then instead to just port this from D6 i should create a new feature with the same functionality just removing the ubercart integration right?

oks, I'm going to start on this at the weekend, in the meanwhile i will assign this issue to me

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

I'm taking a look at this module now and here is a starting patch I have come up with. This patch basically:

• 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

Next I'm going to see how this would fit in with Registration and then Commerce. My open questions are:

• 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.
• 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.

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!

Hey Matt, Atlanta DUG is doing some work here too. Let me know specifically if you need any testing done. We haven't started looking at commerce registration workflow yet but a Skype may be in order. There is no code and no recent discussion here: #1232900: Commerce Signup (D7) - Development approach. We are probably going to use D6 COD for this year's camp but KL is looking at this feature and a way to incorporate it into the ADUG site.

@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.

We took a look at the feature and realized it still had the old D6 dependencies and stopped there to see if any progress was made on Commerce Signup first. There does seem to be some movement at http://drupal.org/project/commerce_registration but the architecture may require some tweaking.

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

+++ b/cod_events/cod_events.infoundefined
@@ -1,44 +1,65 @@
+description = Provides base event managment
+core = 6.x

Not sure why my export is still showing 6.x here. obviously that needs to change in the info file.

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!

I'll be updating Commerce Registration to accomodate some new things in the near future. Going to change a lot of workflow, so I'm sure there will be plenty of issues that arise in order to accomodate a large variety of use-cases.

#16 applied cleanly but I am seeing the feature is overridden as soon as it is enabled.

Visiting the 'Manage Registrations' tab on an Event node causes an error:

Notice: Undefined index: und in commerce_registration_node_registrations_settings_form() (line 61 of ../commerce_registration/includes/commerce_registration.forms.inc).
Warning: Invalid argument supplied for foreach() in commerce_registration_node_registrations_settings_form() (line 61 of ../commerce_registration/includes/commerce_registration.forms.inc).

-- unable to find this error (or similar) searching Google. Looks to be an issue with the commerce_registration module.

Also under registrations/settings 'matthew@mrconnerton.com' is set as the default 'from' address. I imagine this should use the default site admin's email or something like 'admin@example.com'

This is all I have found thus far - this test was silo'd from other modules and I did not check the full workflow/enable any other modules/features besides cod_event and its dependencies.

Attached is a rebuild of the feature with the email bit changed to variable_get('site_mail', 'admin@example.com')

Patch in #20 applied clean, but I am still showing an override on fields.

re: default email address - oops :-)

I will be making another patch shortly to pull the paid registration stuff out. The latest commerce_registration commits have fixed a bit of the workflow issues and I plan to resolve the "every registration should have a user account" issue with rules module. The paid fields and registration types can be its own module so free events don't have to have commerce turned on by default.

I tested the patch in #20 and enabled only cod_events and its dependencies. Since the workflow is not fully defined yet, I only tested settings page and registration of free events.

Below are issues that may have been a change in the commerce_registration but worth noting here.
1.1 Going to Manage Registrations tab

Notice: Undefined index: und in commerce_registration_registration_page() (line 172 of /cod-www/sites/all/modules/commerce_registration/commerce_registration.module).
Warning: Invalid argument supplied for foreach() in commerce_registration_registration_page() (line 172 of /cod-www/sites/all/modules/commerce_registration/commerce_registration.module).

1.2. After saving Registration Settings

Notice: Undefined index: und in commerce_registration_node_registrations_settings_form() (line 61 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).
Warning: Invalid argument supplied for foreach() in commerce_registration_node_registrations_settings_form() (line 61 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).
Notice: Undefined index: und in commerce_registration_node_registrations_settings_form() (line 61 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).
Warning: Invalid argument supplied for foreach() in commerce_registration_node_registrations_settings_form() (line 61 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).

1.3. After saving Email Registrants

Notice: Undefined index: und in commerce_registration_registrations_broadcast_form() (line 165 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).
Warning: Invalid argument supplied for foreach() in commerce_registration_registrations_broadcast_form() (line 165 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).
Notice: Undefined index: und in commerce_registration_registrations_broadcast_form() (line 165 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).
Warning: Invalid argument supplied for foreach() in commerce_registration_registrations_broadcast_form() (line 165 of /cod-www/sites/all/modules/commerce_registration/includes/commerce_registration.forms.inc).

2. Lastly, a nice to have: When editing dates, I think it would be nice to also have the popup dates. Entering this "2012-07-04 10:55:03 +0800" is very geeky for regular users.

Was having problems applying the patch in #20 this time, looked into it, some of the cod_sponsors items got rolled in. Revised patch attached.

Patch #24 applied cleanly. Fields are still overridden. Using diff module shows the overrides are related to commerce. Unsure if there is a way to dump this diff to attach to the thread.

mrconnerton, should we wait to see your patch before progressing? Any ETA?

I have planned some COD work tomorrow and was going to focus on this issue. So 24-48 hours.

i think we can change the status to active

I am still working on splitting this up into two modules, one for free and base event, and another for paid registration and commerce dependency. just hit a few errors and workflow issues I'm working out now.

This patch just removes the overrides I was seeing on cod_events from patch #24, they bothered me :p

might want to add a dependency on Commerce Payment, your rules specify an event that is only available there

We want to make sure that COD doesn't depend on any commerce modules. Anything commerce related should be an optional add-on module.

@japerry - yes that is the final patch i am working on right now.

mrconnerton, I was made aware that there are some changes coming down the line for Entity Registration and Commerce Registration. Can you tell us what portions of that work you are waiting on? We really need to get forward motion on cod_events.

Hi,

Any updates on this? I was getting this error on the last patch. Not sure what I was doing wrong. Perhaps it needs to be re-rolled or something?

WD php: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES (:db_insert_placeholder_0,                  [error]
:db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
    [:db_insert_placeholder_0] => 1
    [:db_insert_placeholder_1] => create paid_event registration
    [:db_insert_placeholder_2] => 
)
 in user_role_grant_permissions() (line 3034 of /var/www/mine.local/cod-dev/modules/user/user.module).
Cannot modify header information - headers already sent by (output started at /home/arnold/.drush/includes/output.inc:37) bootstrap.inc:1239                                                                           [warning]
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
    [:db_insert_placeholder_0] => 1
    [:db_insert_placeholder_1] => create paid_event registration
    [:db_insert_placeholder_2] => 
)
 in user_role_grant_permissions() (line 3034 of /var/www/mine.local/cod-dev/modules/user/user.module).
Drush command terminated abnormally due to an unrecoverable error

I'm FAIRLY sure this is postponed until #1704300: Alter registration field to allow more than one bundle to be selected is complete.

Seeming there are a few different COD 7 sites that have been developed DrupalCamp Asheville and Atlanta, is it possible to get the Dev. Branch built from what they have done ?

This is just a curiosity question.

I don't think it would be a stretch to preserve the dev versions of registration and commerce_registration current branches and start the refactor in new branches. Just have to ask the maintainers

-

I know for Commerce Registration, I moved all new feature/architecture development to a 7.x-3.x branch, and all current workflow/architecture/features are in the 7.x-2.x that will be preserved and fixed with relation to the current version of Entity Registrations.

#35, You need to update Entity Registration. The newer version make the registration field available that the feature requires.

I applied patch #30 to the latest dev. Hunk 1 failed in the .info file, everything else succeeded. I manually applied the .info file. The feature enabled with Commerce and the latest versions of Registration and Commerce Registration (2.x-dev).

It seems like there are 2 reasons this issue is postponed:

A) Paid and free events need to be separated into [edit] COD Events features
- We're not really blocked on this aside from B.

B) Registration (and Commerce registration) need to be rewritten per #1704300: Alter registration field to allow more than one bundle to be selected.

- levelos of ThinkShout would have the best sense of the progress to date, potential timeline and any constraints around progress there.

Depending on the timeline for B, it may make sense to proceed with A in the 7.x-1.x branch of COD and then later work on a 7.x-2.x branch of COD rewritten Registration and Commerce and Commerce Registration modules.

In proceeding on option A, as stated, paid and free events have slightly different setup workflow.

Free
You simply create a node bundle (content type) and add a Registration Type field to it, and proceed using Registration as normal. The user visits the 'event' node page and clicks on Register, enters their info, and is registered.

Paid
You create an event commerce product(s), depending on price level, and attach a Registration Type field to it. From there you need to have a 'product display' type node that has a Product Reference field on it that references any/all of the associate event products. The user visits this display node page, chooses the event product from the select list that he/she wishes to register for, and adds that item to cart. From there the user then goes through the checkout process (first step in the checkout process is entering registration information). Upon checkout completion, the registration is saved.

Pros:
- Separate registration settings on a per-product basis (ie: students vs non students, students you might want to collect school affiliation).
- No unnecessary steps for Free events (no going through a $0 cart/checkout)

Cons:
- Separate workflow for free/paid.
- No event level settings (ie: event capacity 500, but only allow at most 100 students)
- There is no single parent 'event' entity, as the host entity for the Registration is the specific product the user purchased, thus requiring extra steps in the module to be able to see a listing of all registrations or to email all registrants
- Product quantity to registrations are one to one. For a single registration, it references only one product. With option B a single registration has the ability to take up multiple spots (ie: 5 spots for one person registering), and then upon registration, the associated product is added to cart with a quantity of the number of spots.

I think for now option A is close to what COD with UC/Signup does currently in D6. It would at least get a stable D7 version of COD out there with very similar functionality to what (I think) the most common use-case requires.

@jpontani, For both options are you planning on using Commerce Registration 2.x or 3.x?

CR 3.x is a developmental branch that I created to start on the rework of it for when Registration switches to multiple bundles in the field. It has nearly identical code right now, but would change for Option B. the 2.x branch would be for Option A.

Cons:
- Separate workflow for free/paid.
- No event level settings (ie: event capacity 500, but only allow at most 100 students)
- There is no single parent 'event' entity, as the host entity for the Registration is the specific product the user purchased, thus requiring extra steps in the module to be able to see a listing of all registrations or to email all registrants
- Product quantity to registrations are one to one. For a single registration, it references only one product. With option B a single registration has the ability to take up multiple spots (ie: 5 spots for one person registering), and then upon registration, the associated product is added to cart with a quantity of the number of spots.

What about using field collections inside registration entities?
Basically a registration entity would have all the pertinent information for said registration, then a field collection of users and related product references would allow an entity to have multiple registrations.

I'd like to split this into two initiatives..
1) the Information Architecture -- basically the entity and how data is stored
2) the workflow process

Once we get the IA down, it will help drive how we setup the workflow. For instance if we have a field collection with a product reference, and events with product references, we could have a workflow that glues the two together. So if you want to signup for an event at some level, it'd check to see the amount of registrations that have completed for quantity (or use rules to store this number), and allow the user to proceed.

@japerry, we did actually initially consider using field collections the best route for allowing multiple registrants for a given registration and can confirm that approach works. We haven't played around with adding Commerce to the mix, but I don't see why it wouldn't work.

Re: the major change discussed in #43, I started down that road but am really not convinced it's the best path forward. It very likely will create more headaches than it will solve. We're currently building out two sites that using Registration along with Commerce without adding Commerce Registration to the mix as the workflow didn't match. The basic workflow we're using is:

1. Indicate if an event is paid along with the price. Likely via a product reference field, but not necessarily. We're exploring simply adding custom line item to the cart with a given configurable price.
2. After registration form is submitted and registration saved, code detects if it's paid and sets the state to pending and places either the linked product or a custom line item into the cart along with appropriate messaging. Optionally redirect directly to the shopping cart or checkout page.
3. Link registrations to orders with an entity reference.
4. If an order has a linked pending registration, flip to complete after payment processed.

I'm sure we'll run into pitfalls, but that approach is looking promising at this point.

I think there's 2 more cases to consider beyond those 4 items.

2.5: Let people purchase multiple tickets and enter details for those people's profiles as part of checkout. This is a popular feature of uc_signup.
5: After X time period clear out any registrations that are still in a pending status.

Good additions @greggles. Multiple registrants could possibly be handled with field collection as mentioned in #47, or, more simply, with some variation of "save and add another." Party depends if the registrations need to be bound to each other with more than the final order. Clearing out old pending registrations should be pretty straightforward.

levelos and I worked on a mockup of the registration form that sums up the IA that is proposed.

See attached file for details.

In words -- Two Registration related entities:
-- Registration
-- Registrant (formally known as field_collection, and would act similarly)

Registration entities contain the basic information about registration configuration and the registrant. It is fieldable and could contain additional info (top box in the attached scribble)

Registrant entities contain who is actually registered for the event. This could be the person registering (and in many cases registrations just have one registrant), or could be people the registrant registers, or could be the registrant and additional registrants. Pricing is optional, and a field that would be added if the commerce component is enabled.

In the case between 'free' and 'paid', it would be the same select box, where the registrant entity would submit any paid selections to the cart. If there are paid entries on the registration page, clicking next at the bottom would take them to a cart. If there are no paid entries, it'd direct to a confirmation page to save.

When registering in a group, there will be an option to use an email. If the email already exists in the system, a confirmation email would be sent to the account. If the event is selected to create accounts, and the email doesn't exist in the system, it would create an account and send a confirmation email. The registrant also can bypass the emails (in case of registering children for an event) and add fields to the registration.

This architecture should allow for the use cases we've discussed including:
1) Individual Registrations (free and paid)
2) Group Registrations of drupal accounts via email (free and paid)
3) Group Registrations of non-users (free and paid)

If there is another use case that falls outside of this, let me know. One registration type exists for an event, and the commerce component is abstracted out to the product reference field that is controllable just like any other product reference.

Alright I have created a new patch from scratch that does the following:

• Removes references to Signup & Ubercart module
• Removes the install hook for ubercart event product class creation
• Adds a generic event content type with original fields: Date and Image
• Removes the view of signups from old signup module dependency
• Adds a registration field to the event content type
• Adds a "Free Event" registration type
• Creates a new cod_paid_events module
  • Adds a "Paid Product" commerce product type with a field "Registration" type defaulted to paid registration
  • Adds a dependency to the registration, commerce, commerce_features and commerce_registration modules
  • Adds a product reference field to the event content type
  • Adds a "paid product" checkbox to the event content type
  • Adds conditional field settings to show hide the product reference and registration field based on that checkbox
  • node_node_presave to clear out either field value that shouldn't be used
  • Adds a "Paid Event" registration type

I am using the following related modules and versions:

• Commerce 7.x-1.4
• Commerce Registration Integration (commerce_registration) 7.x-2.0-beta3+10-dev
• Inline Entity Form (inline_entity_form) 7.x-1.0-rc1+2-dev
• Registration (registration) 7.x-1.0-beta3+10-dev

I created this patch by downloading all the cod_support dependencies, applying this patch, downloading the new dependencies and then doing a fresh install. After the install I enabled cod_events and it was default after enable. For paid events I enabled cod_paid_events and both events were default after enable.

This patch will provide two workflows, one for free events and one for paid events

Free Events
To create a free event, enable the cod_events module and make sure it is in a default state. Then go to "add content" in your admin menu and create a new event node. You will see a "Registration" field were you can select "Free Event" as your registration type. After you save the node you can configure the registration settings on the registration settings tab.

Paid Events
To create a paid event, enable the cod_paid_events module and make sure it and cod_events are in a default state. Then go to "add content" in your admin menu and create a new event node. You will see a new checkbox that lets you define "This is a paid event". When you check that box the "Registration" field will disappear and a "Product" field/interface will appear. Here (using inline form widget) you can add an existing product or create a new product inline. After you have created and/or added your product, save you node. After you save the node you can configure the registration settings on the registration settings tab.

cod_paid_events also implements hook_node_presave to clear out the value of the registration or product field depending if the event is paid or not.

There is plenty of gravy we can add to this but I think its a great start using the existing entity registration module branches. Shooting out ideas here would be:

• Get people to test this out
• Create rules that will check to see if a registered user exists as a Drupal user, if not create that user
• Create more advanced registration views, reports, check in views, etc

I applied the patch it it showed; warning: 1 line adds whitespace errors. Not sure if this is a big deal.

Installed on a fresh install and there appears to be 2 Overriden sections in the feature:

Registration fields :
+"data" : null,
+"rdf_mapping" : []

Registration type:
+"data" : null,
+"rdf_mapping" : []

The only thing that I am a little confused about is the free or paid events module. Is this going to be build into the Events module or are they going to be separate modules ?

Other than that everything looks good. I registered two people by email and tested the message blast participant a message. Looking Good !

Committed!

3297d3fb9ffca4964d5976be35aa75ff9095b8e1

We will need to work on how we do entities and probably will copy some information from this ticket. but as far as upgrading to d7, this is -DONE- :-)