API change: Allow other modules to verify that an order may proceed to checkout

SHouldn't it just get a dependency?

The offending function is quite small:

/**
 * Returns an array of product line item types.
 */
function commerce_product_line_item_types() {
  $types = array();

  foreach (commerce_line_item_types() as $type => $line_item_type) {
    if (!empty($line_item_type['product'])) {
      $types[] = $type;
    }
  }

  return $types;
}

If we just move it commerce_line_item, then checkout continues to work (it already depends on order which depends on line item).
Seems like that is the only place where we make the product assumption.

Could probably use feedback from Ryan.

The basic idea is that we have to have some sort of assumption about what should be "checkoutable" and what shouldn't. Allowing any line item to register an order as "checkoutable" isn't sufficient, as who knows what types of dangling line items may collect in orders from modules like Coupon and Shipping. Thus the Cart / Checkout system introduce a dependency on product line item types. Granted, now you can simply declare that your line item type should be considered a 'product' for the purposes of checkout on the site, but that's not necessarily the best solution.

Perhaps we simply need "yet another property" for line item types that mark it as sufficient for an order containing one line item of that type to be checkoutable. This may also require changes to the Cart module, as the Cart / Checkout modules together are geared toward the use case of getting products from a node to a completed order.

I'd be hesitant to monkey with this too much on the 1.x branch, but perhaps what we can do is add a point of extensibility to the bit of logic that checks "is this order checkoutable"? In other words, we could keep the default product requirement for checkout but abstract it out of the router and change it from a falsification to a verification - i.e. instead of one module saying "hey, this order can't be checked out" we'd just be looking for one module to say "hey, this order can in fact be checked out."

And really, I suppose that change actually could go into the 1.x branch.

Marked #1249812: Specify in the line item type if it is "checkout"-able as duplicate.

Ahh, thanks Ivo. I knew we'd gone over this before but couldn't remember where. : )

I share my problem that would be solved by this to show a possibe use case that may give ideas:
I have to provide an option for shop admins to compose orders manually for the customer in response for a quote request for a renewable energy generation system. For this, an order should work even without any products, just by entering titles, unit prices and quantites for line items.

I'm currently workin on a project, where we simply want to make userpoints purchasable, and therefore products are not needed. I try to decouple the current implementation and provide a patch for that.

There is the patch, that simply removes the dependency and builds some wrapper to make it more clear, and so does not change the API in any way.

The patch in #12 still uses commerce_product_line_item_types() when I suspect it should be using commerce_checkout_checkoutable_line_item_types().

@Dippers you are totally right. There's the correct patch.

This patch adds additional option to select what line_items can be used for the checkout process, you may consider excluding the product line item using this patch and create your own (this will remove the product dependency in the checkout process). This can be done through the admin menu for commerce_checkout module.

I have added the menu item that was missing from the last patch so you can get to the settings form, and made the form a system settings form.

I have also namespaces the variable and made the check in the checkout router fall back to the previous behavior if the settings have not been changed.

Patch now encoded in UTF-8

I'm going to bring this back to my comment #6 above. The approach that developed seems to be rooted in a prior contributor's desire to have a form to make more than one line item "checkoutable", but all it does is provide a user interface without really addressing the underlying issue as declared in the title - allowing other modules to verify an order may proceed to checkout.

As far as I'm concerned, that means it doesn't really make sense to use the patch that's developed, though I do appreciate the effort put into it thus far. What I recommended in #6 was that while a property that determines if a line item is "checkoutable" or not would be an interesting solution, but ultimately I'm hesitant to add that to the data structure at the present time.

My recommendation was to instead create a new function that we use to determine if an order can proceed to checkout based on its contents (e.g. commerce_checkout_order_can_checkout()) that starts with a FALSE return value, can set that to TRUE if it passes the check for product line items, and then allows other modules the opportunity to return a TRUE value as well via a hook. That may involve simply supporting additional line item types, but that wasn't the most interesting part of the solution.

Given this is more abstract and that line item types are currently primarily governed by code, I don't see a need for a user interface for this.

Try this one out. : )

Awesome. I added a @see comment but stayed with the inverted logic since the default assumption here is that an order shouldn't be considered "checkoutable" unless some module says so (at least as far as the original logic here was concerned re: line item types on the order).

Thanks for the review!

Commit: http://drupalcode.org/project/commerce.git/commitdiff/f8f056b

Sorry to re-open this issue, but just wondering if there is an intention to add a similar call to commerce_cart_checkout_router() used for the 'checkout' menu router item? A patch to achieve this is attached. I also set repeat to FALSE on the dsm() since I was getting duplicate messages, not sure why.

@bgilhome, I believe you'll have to open a new issue to address your question in #30