Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 957662-order-type-api.patch | 7.37 KB | Damien Tournoud |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedFirst 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...).Comment #2
rszrama CreditAttribution: rszrama commentedYeah, 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.
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedWhat 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.
Comment #4
rszrama CreditAttribution: rszrama commentedI 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. : ?
Comment #5
rszrama CreditAttribution: rszrama commentedOk, 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...