I sense that having support for order types (at the API level) will be very useful.

Use cases include: building an order-splitting logic to send orders in several independent systems, managing completely different types of orders in the same site (like donations and standard ecommerce orders at the same time), etc.

I don't believe we need to ship with an UI for this.

CommentFileSizeAuthor
#1 957662-order-type-api.patch7.37 KBdamien tournoud

Comments

damien tournoud’s picture

damien tournoud commented
Status: Active » Needs review
StatusFileSize
new 957662-order-type-api.patch7.37 KB

First shot at this.

What's missing is deciding what to do in places we currently hardcode the 'commerce_order' bundle (especially in the checkout process...).

rszrama’s picture

rszrama commented
Status: Needs review » Needs work

Yeah, the question of "default" order type is a very important one. That can just be a shopping cart setting if necessary. The problem with no UI is that there is an order settings page where users can manage fields on orders. It would seem silly to introduce API level support to have multiple order types but not design the default UI to support modules adding order types.

I think it makes good sense for us to have core support in the sense that if multiple modules need to plugin to this, there's no reason for them each to enable bundling orders. I left it as no bundling for 1.0 for simplicity's sake (there was plenty else to worry about), but if we're going to change it, I'd just as soon go the full way as half an introduce a UI like the customer profile / line item type management interfaces with some way to specify the order type Cart should use with an order type selection screen for creating orders from the backend.

damien tournoud’s picture

damien tournoud commented

What I meant by "API-level" was that I don't believe there is a need for storing order types in the database.

Field UI for order is debatable. I would be happy with just the UI for default order type, with other UI added in by the additional modules.

rszrama’s picture

rszrama commented

I got your meaning - it's the same way it works for customer profile / line item types. They can only be module defined w/ no database storage support. We could have a "smart" UI that degrades to the single menu item when only one order type is available. : ?

rszrama’s picture

rszrama commented
Title: Add API-level support for order types » Add database level support for order types
Status: Needs work » Fixed

Ok, Damien and I talked about this a bit further in IRC. Without going the full 9 yards and adding extra permissions, a UI to select default order type, UI to manage fields on different order types, we figured the minimum work would be to get the order type in the database. I committed a variation of Damien's patch with support for setting the type on order creation via the controller.

Part of me feels like we made a mistake here, walking back from a full on hook to just depending on altering the entity info array. However, if we're not going to provide a full implementation of order types, it "feels" right to not really define order types to the level of product types, line item types, etc.

I'm happy to be told otherwise (especially if I misunderstood you, Damien). : )

Commit: https://github.com/rszrama/drupalcommerce/commit/639dc150e8b76a435e0858a...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.