See #1497284: Create registration_commerce glue module for use case and details.

Comments

levelos’s picture

levelos commented

@jpontani, awesome work on the Commerce integration so far. We need this workflow as well, and I'd love to collaborate and focus all reg/commerce in one place. Any further thoughts on implementing this? Is it on your short term radar? I did a bunch of playing around, adding product fields to registrations and adding both commerce and registration fields to a parent entity, with no obvious solutions arising. Happy to chat in IRC as well ...

jpontani’s picture

jpontani commented

I think this will be easily handled as soon as #1417414: Add an API function to determine the "first" checkout page gets resolved. The problem currently is that if I try to set the Registration Information page weight to be before the Checkout module's page, the Checkout system breaks.

Otherwise I'd need to set up a custom form and have the user redirected to that rather than the Cart and upon completion of that, they are then redirected to the appropriate Checkout step.

I'm not sure how I wanted to handle it so I just put it on hold until the above issue had a clear direction of either being implemented or not.

levelos’s picture

levelos commented

That would work, but would still disrupt the default registration workflow. Thoughts on something along the lines of:

  1. Admin adds commerce reference field to a registration bundle.
  2. Field is optional, and includes products like "full day", "half day", etc.
  3. Registrant optionally selects a product when completing their registration.
  4. commerce_registration takes over and adds the appropriate item to the cart, if applicable, and creates the registration in a pending state.
  5. when an order is completed with a pending registration in the cart, the status is flipped to complete.

I can think of 2 main issues this workflow helps with:

  • Allowing for paid and free registrations to the same event.
  • Making sure that an event doesn't get sold out during the checkout process
jpontani’s picture

jpontani commented

Probably would work better that way.

As for the registration status, I'm actually just using Rules to do that as Commerce requires Rules anyway. I'll leave the business logic up to the end user.

I'll start working on it, probably release it as 2.1 since it's not that big of a change of code base.

jpontani’s picture

jpontani commented

So I spent some time thinking about this direction, and a big issue came to light.

Since you're registering for a parent node that has the registration, only that node has registration settings. There is no way to have per-product registration settings (open/close date, registration limit, etc).

Say I want 3 product types, 3-Day, Single Day, and Half Day passes. I want all to open registration on the same day, but 3-Day passes I want to end a week early and only sell 100, but the Single and Half day passes there is no limit. By reversing the association from product -> registration to be registration -> product, I have no way of setting distinct registration settings for each product, as the registration is the parent, rather than the product.

seanberto’s picture

seanberto commented

Thank you again, jpontani, for working with Lev and the rest of the entity registrations cadre on this commerce integration.

I do wonder if two different sorts of use cases are getting conflated in this discussion.

ThinkShout's interest in having the commerce workflow follow the registration workflow is for the following use case:

* We have a single event with a single registration limit.
* The pricing of that event differs depending upon a user's role or other arbitrary reasons (like, a student discount rate).
* Over all, we want the registration workflow to be the same for these paid events, as it is for unpaid events.

I think that the use case that you've raised re: day/half-day passes with different registration limits, is a bit different. For your use case, it seems like you could manage these as different types of events (or registration opportunities).

If we go with the solution that Lev's proposed, but also want to solve your use case, it seems like you could set things up as follows:

* Create a content type called "conference."
* Create a content type called "pass" (ie, 3-day, single day, half-day).
* Use entity reference to add "passes" to the conference node(s).
* Each pass would have a registration field - potentially referencing different registration bundles.
* Each registration bundle would have a product field referencing one or more product entities.

This way, you get multiple price level options per "pass." You can also manage different registration limits per type of pass.

Does this make sense? Admittedly, I'm somewhat removed from the code. Just thinking out loud here.

ezra-g’s picture

ezra-g commented

I did some testing of this workflow related to COD at http://drupal.org/node/1150318#comment-6030924 . Since this seems to be the issue where collaboration around the registration workflow is happening, so I'm cross posting here so that jpontani and the levelos folks can be aware.

jpontani’s picture

jpontani commented

Created a new branch (7.x-3.x) that will handle this new workflow. Patches welcome :)

brentratliff’s picture

brentratliff commented

I'm going to give it a shot for my college reunion site. I'll patch what I can :) I'm not sure we're ready to try it yet for Drupalcamp Atlanta this fall.

ezra-g’s picture

ezra-g commented

I filed #1663222: Document Permutations of registration options in the COD_Support issue queue to try to help establish some documentation of all the various permutations of registration options here.

jpontani’s picture

jpontani commented

My main concern is in regards to #1663222: Document Permutations of registration options, where the workflow requested is to initially add products to a cart and then gather the registrant information once the user is done choosing what they want to register for.

The current workflow of Commerce Registration follows this in that the user adds products to the cart and then enters registration info when they're starting the checkout process.

By reversing this process, you are then entering registrant info up front, and then having the product added to the cart. So if I want to register multiple people, I have to go to the event page and hit "register", enter registrant info, and then go back to the event page and repeat that process for each person I want to register.

Or once I've already added my registration/product to the cart, but then upon viewing my cart I decide to go ahead and register another person. If I update the quantity of the product to 2, we would then have to force the user back to the registration info pane before they can do anything else such as add other products to their cart.

Commerce Registration places an initial step right at the beginning of the checkout process in that it gathers information regarding the registrations (such as quantity, which entity the registration is for, etc). It just utilizes the available form builders, validation, and helpers that Registration provides. This also provides for functionality such as custom registration settings per product as I have mentioned in comment #5; this is accomplished by having the product be the parent.

For free events, one could easily just add a registration field to a node, and use Registration module as normal without Commerce Registration ever stepping in to do anything.

jpontani’s picture

jpontani commented

As a follow up, by having the user fill out registration information first and then having the necessary product added to cart, you changing the default flow of:

Cart > Registration > Checkout

and changing it to

Registration > Cart > Checkout

ezra-g’s picture

ezra-g commented

And, the benefit of doing Cart > Registration > Checkout is that we can stream line the process (as UC_Signup does now).

blacklabel_tom’s picture

blacklabel_tom commented
Issue summary: View changes
Status: Active » Closed (won't fix)

Closing this ticket as the https://www.drupal.org/project/registration_commerce module works on this basis.