Order types are defined as bundles for orders, but not visible in the UI. Still, they introduce complexity for users, e.g. as modules like Rules know there are bundles and takes them into account. Handling orders with Rules would be simpler if the order-type would not be exposed as bundle.
See the patch attached.
Sill, one could manually re-activate order-types by code. Although I'm not sure about use-cases.
Related, the same issue appears for customer profiles. Do we need multiple bundles there? Maybe order types should use a fixed customer profile type, so one can save a bundle-check again. Goal: Make something like commerce-line-item:order:commerce-customer-billing:commerce-customer-address:country directly accessible in Rules -> UX++
| Comment | File | Size | Author |
|---|---|---|---|
| commerce_order_no_bundle.patch | 926 bytes | fago |
Comments
Comment #1
rszrama commentedHmm, we intentionally supported order bundles in core so that site developers could take advantage of them if they knew they needed them. At the time the decision was made, though, we didn't have a plan to add a UI to specify default order types and such. Our database schema includes a type column for orders already... I'm wondering if there would be any adverse side effect to not defining the bundle properties in hook_entity_info() or if the data could still be present just the same without the additional headache for users who don't even know this is a low-level possibility.
As for customer profile types, those definitely need to remain as we're using this feature in the Shipping module. We add a shipping information profile type to handle the collection of a shipping address in a separate checkout pane. (Internally, we've also used custom customer profile types that don't include address fields to collect meta information about the customer within their company.)
Comment #2
fagoYep, I think leaving everything as it is, but just don't advertise the oder-type as bundle should do it. Developers can still re-advertise the oder type as bundle if they want to make use of order types. That - would then require updating their Rules which assume there are no order bundles though.
I'm wondering, what are the use-cases for having multiple order types? Having multiple "shops" on a site?
I think the current situation is UX wise bad. Order types are hidden from the UI, so users are not aware of them. Thus users don't think of having to check for order types in Rules.
@consumer-profiles:
I see. Is the relation order-type <-> customer profile type fixed though? If so, specify the 'bundle' key in the entity reference makes Rules know it and users save the condition.
Comment #3
damien tournoud commentedThis feature is intentional and there are important use cases for it (the most important one being the capability to do "order splitting" between customer and supplier orders). I don't think it's a good idea to remove the bundle key either... as soon as you enable a module that re-add it, all your rules are going to become invalid.
I think it's mostly a UI problem, couldn't the rules UI add a "is of bundle" rule by default when creating a new reactive rule? Having a way to define a rule template per trigger would be very useful.
Comment #4
fagook, I see.
Indeed.
Agreed, we should work on easing that in Rules. However, that does not help in case the order is just referenced from somewhere, e.g. a line item. We should make sure commerce specifies the 'bundle' key for relations like that and provided variables if possible. E.g. the customer profile bundle should be known per order bundle, shouldn't it?
-> Re-titling and categorizing issue.
Comment #5
bojanz commented