This happens when removing line items from the Order Edit screen. Able to reproduce in custom profile, and commerce_kickstart with Commerce 1.8.

Comments

rszrama’s picture

Category: bug » support
Priority: Minor » Normal
Status: Active » Postponed (maintainer needs more info)

I cannot reproduce the issue, and I can't imagine a scenario in which the $order object would be missing a basic property. Any insight into what caused your $order to lack that in the first place? Perhaps the order was created in some other method than using commerce_order_new() such that it was missing data and hadn't been saved / loaded yet before being passed to this function?

favrik’s picture

Yup, It's pretty weird. Going to re-install commerce_kickstart and then update Commerce to 1.8 and test again.

favrik’s picture

Ok, here's what I did to reproduce on new install of just Commerce Kickstart 2.8:

1. Go to /admin/commerce/orders
2. Click "Add an order" button
3. Under line items table, select "Product" and click on "Add line item" button
4. Find any product and click "Add product" button
5. Save the order
6. Click on the "Remove" checkbox and then Save the order

rszrama’s picture

Category: support » bug
Status: Postponed (maintainer needs more info) » Active

I'm not sure why it only happens in that scenario, but I can confirm the bug. It appears that the order is being saved once with an empty hostname string, so the property is actually unset() to prevent removing whatever hostname may be stored in the database. Then somehow that order object is being saved a second time. We can either fix it with your patch or look for a deeper fix - perhaps one that forces a load after the save so we actually save a new order object... otherwise I get the feeling we could be overwriting other data.

rszrama’s picture

Yeah, the issue appears to be that the line item gets deleted first, so commerce_line_item_delete_references() is invoked to save the order after the line item has been deleted. Then the order edit form submit handler completes and saves the order, and at that point in time it's missing the hostname (and potentially other properties).

jsacksick’s picture

I also noticed that issue and it seems that the hostname is unset because the value of the hostname is not set in the first place when saving a new order because of the following condition in the controller :


      if ($order->is_new && empty($order->created)) {
        $order->created = REQUEST_TIME;
        $order->hostname = ip_address();
      }

So for instance when creating an order via the admin UI, we're setting the created property value in commerce_order_order_form_submit() before saving the order.
Because of the above condition the hostname is not set and it will be wiped in the else condition.

jsacksick’s picture

Status: Active » Needs review
StatusFileSize
new910 bytes

The attached patch seems to work for me.

kalistos’s picture

I cannot reproduce the issue, and I can't imagine a scenario in which the $order object would be missing a basic property.

I confirm that this bug exists and can reproduce it and can show it if you need.

https://drupal.org/node/2049515#comment-7684929
A bit strange patch, but it helped me. Thank you.

say.hello’s picture

I am using Drupal Commerce 7.x-1.8. The original problem does not occur in this version, but the error message also occurs when the following is done:

The intention is to create an order with a special product for a customer. The customer uses the web shop to pay for the product.

1. Log in as administrator that can create orders.
2. Go to /admin/commerce/orders
3. Click "Add an order" button
4. Under line items table, select "Product" and click on "Add line item" button
5. Find any product and click "Add product" button
6. Set the status of the order to e.g. Shopping cart.
7. Assign the order to a normal user, let's call the user "customeruser"
8. Save the order

9. User "customeruser" logs in and goes to the checkout page.
10. User "customeruser" proceeds to the Review order page.
11. The error message is displayed on the Review order page.

rszrama’s picture

Issue summary: View changes
Status: Needs review » Fixed

I've confirmed the problem afresh and tested jsacksick's patch successfully. Upon further review, I don't see how this could lead to data loss, so I'ma move forward with it. Thanks for the fix Jonathan and for the feedback everyone else. : )

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

Status: Fixed » Closed (fixed)

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