Update line item price with Inline Entity Form on order edit

I'd say it should go in IEF, though saving an order should cause the order total to be recalculated. The thing is that order total calculation depends on the summation of all line item total price components, not just the addition of price field amount columns as a direct edit would perform. This means IEF needs to be able to create a price component inside these line items when a price is adjusted to reflect the difference or else recalculate the price component arrays from scratch whenever saving with a manually edited price.

I will test whatever version you guys decide on, and think will continue to receive support. Just let me know what you need from me. I can test, but I am not a coder.

I am using Using Commerce 7.x-1.3, Customizable Products 7.x-1.0-beta1, inline entity 7.x-1.0-beta3 (I can move to dev if that helps testing).

On the user order form, everything works fine. On the admin-entered order form, I have the following problems:

1. The price for the sku is not entered automatically. This is an inconvenience, but for some of the site members, this will be a source of great frustration (low tech users).
2. The form does not calculate the price AT ALL. So, even if I manually enter amounts, which show in unit price and the line-item total, the final total is not calculated at all. This is true for both new orders and edited orders. Note that this is true if I edit or create a new order, and it remains true even after I save the order: https://skitch.com/mariagwyn/efkmg/orders-the-orthodox-theological-socie.... Note this screenshot is of an order that was newly created, saved, edited, and saved. Neither price seems to be totaled.

My site will have at least half of its orders added by a treasurer, so I am eager to help with a solution, though my abilities are limited to testing and breaking things.

Maria

I'm not sure how that should be covered by IEF, it's not up to IEF to know where it gets used. Instead I guess the order module should care about possibly needed order total recalculations if a line item of the order gets its price changed.

Moving back to Drupal Commerce queue for re-consideration.

Honestly, I'm not sure what the issue is here I guess. My first impulse was to move it to IEF because that module does make special accommodation for line items that I assumed could be interfering with the normal order total calculation process. Additionally, I don't experience any issues adding line items and adjusting their prices on the create order form without IEF. I just added a $10 product to a new order, changed it to $17, and saved the order. Voila, my order total was $17.

The issue with cart based recalculation seems like a red herring to me.

Perhaps we can get a recap of what the base problem is and how to reproduce it. If reproducing it isn't possible without IEF, then we should move this back to its queue. And I need to know if you're talking about manual adjustments of line item prices or expecting pricing rules to fire (which do depend on the cart statuses).

Moving this to IEF's queue, then. I suppose we'll need to determine why the order total isn't being recalculated on save, but that only seems possible if you're editing the line item via the inline form and not saving the order form itself. In that case, I'm not sure why the line item data would be changing. Maybe it's a cart / horse thing - perhaps the order is being saved first and then the line items are being saved for some reason.

cjgriffin, sorry for the silence, I got distracted by other projects.

Just so you know, I am a very novice commerce user, this is my first commerce site. I seem to be stuck between rock and, well, ...you get it. Here is the situation:

I have a product, 'membership' that gives registrants the option of selecting a journal subscription. It is just a radio field. It works fine when a user creates the order, etc. However, many members will send in their order via snail mail. So, an admin must enter the order on the site. Here are the problems:

IF the widget is LINE ITEM MANAGER:
The sku is entered, the price is correctly entered
BUT no option to choose the subscription. This is a problem.

IF the widget is IEF,
Able to choose subscription as a part of adding a line item.
BUT price is not calculated correctly. Note that this is NOT the result cgriffin describes in his recap. It is not a problem just with editing prices, but creating the order in the first place.

My preference is to use IEF since, if I understand correctly, it is IEF that will be maintained. So, cgriffin, can you share the rule you created to 'trick' commerce into think that admin orders are 'cart' orders? I get the idea, but I have no idea where to begin actually construction such a rule.

Thanks,
Maria

The http://drupal.org/project/commerce_checkout_admin module (was a sandbox now full fledged) sorts this for now in my scenario. Thanks Chris!!

Hello Everyone,

I experienced the same issue when usuing this widget (awesome widget by the way).

And I just updated to the latest version (1.0 rc1) with the hope of seeing it solved, with no luck. I dove into the code and found the problem.

It is in the hook_field_attach_submit where the line items are being saved that the pb occur.

Starting Line 1115

foreach ($values['entities'] as $item) {
        if ($item['needs_save']) {
          $controller->save($item['entity'], $context);
        }
        $entity_ids[] = array($values['settings']['column'] => entity_id($entity_type, $item['entity']));
      }

You simply need to add a call to the commerce_line_item_rebase_unit_price($item); just before the $controller->save(...) one

Of course this will make the module "un-update-able" and it would be great if this fix (after review and eventual optimization) could be added to the module.

Thanks

:) Thanks Chris,

I actually needed this functionnality hard and I have to comply with specific performance constraints.

By the way, I would gladly help on improving some parts of this module. For instance I would need to output multiple entity types for a same field (line_items field with different line item types: Products, shipping, bundle products etc...) and I would like to have different tables for each entity type with their own custom header fields. For now the fastest way I thought about for this is to put all the fields definition in the defaultFields() controller method and then perform conditionnal outputs in the theme function. Probably not the cleanest way to go but time isn't my friend on that one... Shall I go ahead and work on this alone ?

I'm not sure what you mean, JulienF.
The line items example you gave is about showing different bundles (which we already support), not different entity types.
But if you're showing different bundles (or even entity types), then you must have one common header for all of them, no?

Hello Bojanz,

Actually right now I have the following line item types:
- Single Product
- Shipping
- Bundle Product

All have custom fields and I want to add some of those fields in the table header to show some more info than the regular ones.

For instance
- On the single product I would like to show the following added fields: - Cost, -Dimensions, -Color, etc...
- On the Shipping I would like to show the following: -Cost

I don't mind having a Dimension and color field in the header of the table with empty fields for the shipping line items.

Right now, if I add the "Dimensions" field in the defaultField method, I get an error whenever I have an order with a Shipping Line item as this field doesn't exist for this specific bundle.

#14 is what I was missing! Big thanks, cjgriffin.

Committed:
http://drupalcode.org/project/inline_entity_form.git/commitdiff/6dc0a5a

@JulienF
That's a discussion for #1521274: Investigate a UI for configuring table columns (which fields and in what order) then.