Add "before displaying checkout" event for custom checkout restrictions

I think you will need a custom module for this at present.

Having said that I think a useful feature request would be a "Before displaying the checkout page" CA/Rules event that lets you run conditions on the order and then show a message, run conditions against the order, etc. if the conditions are not met. So, let's refocus this issue on that.

New features go in to 7.x-3.x first. Please submit a patch if you'd like to see this put into Ubercart.

It would be simple enough to add an event that is invoked before displaying the checkout page. The problem is a matter of getting some sort of proceed/abort signal after executing a rule. I don't know the best way to get information back from a rules_invoke_event() call, as it doesn't support passing variables by reference.

Once that's figured out, it would reasonable to add an "Abort Checkout" action which would print an error message and indicate that checkout shouldn't proceed.

I intend to write a module to do something similar in the next month or so. It maintains a list of Rules conditions that must be true for checkout to complete. It lets the customer get to the checkout page, but displays a checkout pane with appropriate error messages if the checkout can't proceed. Attempting to complete checkout will just update the error pane and cycle back to the checkout page if there is a problem.

Also, BullMoose asked for the order to be checked for a minimum number of products from a specified taxonomy term. There isn't a Rules condition for this at this time, right? There probably should be.

Ok, this patch adds a "Customer starts checkout" event and an "Abort Ubercart checkout" action.

The "Customer starts checkout" event is invoked right before generating the checkout form.

If a rule is triggered by a "Customer starts checkout" event and executes an "Abort Ubercart checkout" action, the user is sent to the cart page and Drupal puts a user-configured error message on the page.

I've tested this to enforce order quantity on customers with a "wholesale customer" role. It works and it's exactly what I needed.

Oops, left out a t() or two.

I'm feeling pretty uninspired with my messages ("You can not check out") and labels. Feel free to suggest something better.

Can we not do this a much simpler way? Just invoke the event, don't do any special processing, and let the user use the "Display a message on the site" and "Page redirect" Rules actions to display a message and abort checkout if that's what they want. This way we don't need the separate "Abort Ubercart checkout" event at all, and it's even more flexible in terms of messages and deciding where to redirect the user to.

I didn't know about using page redirection to abort something like this. Now I do.

Here's a patch with just the event, with no extra actions. I tested it with system messages and page redirects, and it works just fine.

I also added a hook for starting checkout.

In other news, I noticed that the uc_checkout_complete Rules event really ought to be named uc_cart_checkout_complete, and hook_uc_checkout_complete() really ought to be named hook_uc_cart_checkout_complete(). It's obviously too late to just change that, as it may break things. What's the right approach here? Just leave it until Ubercart 4? Duplicate them with the correct names, deprecate the old names, and remove them in a year?

This looks better. Though, if we're going to pass $account to the hook, we should pass it to Rules as well for consistency. But do we even need to pass $account? Isn't the current user (ie. global $user) going to be the user that starts checkout?

We don't need to pass $account. I did it that way because that's how hook_uc_checkout_complete() does it, and I was trying to maintain consistency.

Note that hook_uc_checkout_complete() also doesn't need it. It takes $account straight out of $order, and any hook implementation could do the same thing.

Here's a version without $account. Use it if making sense is a better idea than maintaining consistency.

Committed #10, thanks for working on this.

You're welcome.

Bullmoose's original request also requires checking to see if there are min/max products with a given taxonomy term. Should we create a new feature request to add that as a Rules condition?

I guess that should be a new feature request, but I would hope for a more generic solution, entirely Rules based if possible. There is a "list contains item" condition, I wonder if we can extend or reuse this somehow to look through the list of products in the order, and ideally filter on any other available Rules condition.