No line items in order for customer

I'm not sure if the ins and outs of the Views access there, but there are other issues in the queue dealing with absent product line items. Typically they deal with "view product" permissions, though, not nodes via that relationship. If you enable "view any product" permissions for the other users, for example, do they have access? If so, there's a long discussion with a couple temporary strategies for working around this while we figure out the best solution.

Ok, hopefully something turns up... it's typically some sort of entity access problem. May just have something to do with the node access control you're using.

Have you tried the permission "View own orders of any type"? The View "commerce_user_orders" is set to this permission my default. Hope this works for you.

Closing this unless further information comes to light on how to reproduce the problem from a clean install of Commerce Kickstart.

Got the same problem, user can view all order fields, also "Order total", but not Line item list, instead of items it see "No line items found." text.
View "commerce_line_item_table" have no permission limit, user have "View own orders of any type" permission.
What can I look else?

List is showed up if I add "Administer line items" permission to user, but it is not so good solution. Maybe Line item module needs "View line items" permission?

@Murz There's still nothing we can do here until you (or someone else) provides step-by-step instructions to reproduce the problem on a clean installation of Commerce Kickstart 1.x. Have you edited this View at all perhaps?

On a clean installation of Commerce Kickstart 1.x. I can't reproduce the problem, so the problem is after upgrades from older versions (I start from beta), I'll try to import views and compare other options.

I'm having the same issue with a version of commerce updated to the latest dev. The user I am testing with has 'View own orders of any type', 'View own Order orders' and 'View any product of any type' permissions.

I have found that the problem lies somewhere in where commerce alters the select query:

SELECT commerce_line_item.line_item_id AS line_item_id, 
commerce_line_item.created AS commerce_line_item_created, 
commerce_order_commerce_line_item.status AS commerce_order_commerce_line_item_status, 
commerce_line_item.type AS commerce_line_item_type, 
commerce_line_item.line_item_label AS commerce_line_item_line_item_label, 
commerce_line_item.quantity AS commerce_line_item_quantity, 
commerce_line_item.line_item_id AS commerce_line_item_line_item_id, 
'commerce_line_item' AS field_data_commerce_unit_price_commerce_line_item_entity_typ, 
'commerce_line_item' AS field_data_commerce_total_commerce_line_item_entity_type 
FROM {commerce_line_item} commerce_line_item 
LEFT JOIN {commerce_order} commerce_order_commerce_line_item 
ON commerce_line_item.order_id = commerce_order_commerce_line_item.order_id 
INNER JOIN {commerce_order} co ON co.order_id = commerce_line_item.order_id 
WHERE 
(
  (  
    (
      commerce_line_item.line_item_id = :commerce_line_item_line_item_id 
    ) 
  )
  AND
  (
    (  
      (
        commerce_line_item.type IN ('product')
      ) 
    )
  )
)
AND
(
  ( 
    (
      co.type = 'commerce_order'
    ) 
    AND 
    (
      co.uid = 6668
    ) 
  )
  OR 
  (
    co.uid = 6668
  ) 
)
AND
(
  ( 
    (
      commerce_line_item.type = 'commerce_order'
    ) 
    AND 
    (
      commerce_line_item.uid = 6668
    ) 
  )
  OR 
  (
    commerce_line_item.uid = 6668
  ) 
) 
ORDER BY commerce_line_item_line_item_id ASC

So clearly a condition on the non-existent uid column in the commerce_line_item table is the culprit here. I'm not sure yet why it is adding that condition in, but it seems to be coming from within the 'commerce_order_query_commerce_order_access_alter' functions.

Note: I am not working from a clean install, but an updated version.

Ok so since:

function commerce_order_query_commerce_order_access_alter(QueryAlterableInterface $query) {
  commerce_entity_access_query_alter($query, 'commerce_order');
}

.. and the $base_table is 'commerce_line_items', then line 1120 of commerce.module that adds the uid condition is attaching the condition based on the order entity's ['access arguments']['user key'] to the wrong table.

I guess what is needed here is a check somehow that the base table and entity_type match.

The problem seems to be that the query is altered twice, and one of the time seems to fail big time. I suppose Views is somewhat to blame, can you try removing the relationship to Order to see if that fixes the problem?

Just came to the same conclusion. I tried reproducing with a fresh install as well. If you add the relationship to the order then the query fails.

Sorry and the answer to you question is "yes" if the relationship to the order is removed then the view shows results. As soon as you add it, it fails.

I have the same problem, here are the two relationships I have in the view "commerce_user_orders":

- Commerce Order: Line items
- (Line Item) Commerce Line item: Product

Same here.
Shopping cart form view.
Adding relations :

Commande Drupal Commerce : Line items (default)
(Order item) Commerce Line item : Product (added)

Causes the cart to display nothing. Checked permissions, didn't see anything that would help products being seen in that case. I'd go for a query issue as disabling SQL rewriting seems to solve it (don't know that impact it has).

I have found the problem! This is in my custom module, so commerce_order saved with correct links to line_item_id, but in line_item object order_id = 0.
So administrator can view this order with line items, because it have permission "view any line_item", but user - not.
This problem is created in my code like this:

   $order = commerce_order_new(0, 'checkout_complete');
$product=commerce_product_load($product_id);
$line_item = commerce_product_line_item_new($product, 1, $order->order_id);
commerce_line_item_save($line_item);
commerce_order_save($order); 

In this way when $line_item is created, $order->order_id=0, it filled correctly only after first save. So if I do double save, all works well:

   $order = commerce_order_new(0, 'checkout_complete');
commerce_order_save($order); 
$product=commerce_product_load($product_id);
$line_item = commerce_product_line_item_new($product, 1, $order->order_id);
commerce_line_item_save($line_item);
commerce_order_save($order); 

Maybe mistakes like this exists in other modules, that provide this issue.

fwiw, you can read more about using the API to save the proper IDs here: http://commerceguys.com/blog/creating-orders-drupal-commerce-api

rszrama, big thanks for the example! But can you describe why we must create entity wrapper instead of working directly with entity?
Why you don't use one string:
$order->commerce_line_items[LANGUAGE_NONE][0]['line_item_id'] = $line_item->line_item_id;
but use wrapper:

 // Add the line item to the order using fago's rockin' wrapper.
$order_wrapper = entity_metadata_wrapper('commerce_order', $order);
$order_wrapper->commerce_line_items[] = $line_item; 

And creating new order with state 'checkout_complete' is normal or better to create with 'checkout_checkout' and after this move to 'checkout_complete' and 'pending'? (I need to create new order in pending state without user confirmation)

I don't suppose there is a better or worse way; I just tend to use the entity_metadata_wrapper() when manipulating field values for simplicity. As to the order status, it really just depends on what you need to do. Creating it in checkout_checkout has the advantage that on load it will trigger the shopping cart refresh to recalculate prices. But since you're doing this with the API, you could always call the refresh function directly.

Just to contribute, I was experiencing the same problem. In my case I also have additional relationships added to show product attributes on order views. Granting the permission "View any product of any type" reveals the line items on the user/*/orders/* page for customers.

I also have the same problem with a fresh install

I have hane enabled "View any product of any type" but but shill get the "No line items found."

I found my problem it was with my relationship field "(Order) Commerce Order: Payment Transaction"
I have the "Payment Method Example module" enabled - I removed this field an everything works smoothly

Untrusted users should not have access to view payment transactions, for what it's worth. Be careful assigning that to customers...

Also, this is so old, I'm going to close it out since the most recent permutations of the question seem to have been answered. For the others it was likely the longstanding issue with product view permissions.

This may be old, but its still a problem for me. I am only having it with one product type. I have 2 product types:

Registration Product
Product

Both show up in the cart OK, go through the whole checkout process OK, but on the completion page and the emails only the Registration Product works. I get the "No Line Items found" message for regular Products.

I have tried all the solutions I saw above, opened up permissions to everything suggested and also checked Disable SQL on all commerce views, still nothing controls the output of the token used to display the final order.

As far as I know, the token in question is not something we define. If your issue isn't with access control or field level permissions, I have no way of determining further what it may be. My recommendation would be to join one of the open discussions about Views support for anonymous users (assuming your issue is with anonymous customers only). Otherwise all I can really suggest is placing debug code in whatever module is generating those tokens to see what data is available at the time of. Sorry I can't help you further.

"is not something we define." ... Though it must come from somewhere. Is there a view that is used to take this over? If so, I can focus primarily on that.

Honestly, I'm not sure. I feel like there is a module that lets you determine what display formatter gets used for field tokens, but I don't know if it's the main Token module or something else.

missing paren

Just some extra info on this - as it seems I had the same problem
I created a module to send emails (a classic rendered order view) to the new customer and the administrator for new orders. However, and for anonymous checkouts, emails where empty of products (No line items found). Both administrator and new customer when logging in, could see just fine the order.
After disabling "sql rewriting" problem was fixed.
So it seemed, that emails where created (as expected) as anonymous user and probably for that reason some access check was filtering the line items!

A lot of permissions is mentioned. To quickly see if it had something to do with permissions, I hacked core temporarily to make user_access always return true (do not do this on production server!). I still got the message that no line items were found. I then made my function log in before the entity_view('commerce_order' was called, and the line items showed up.

global $user;
$user = user_load($order->uid);

I then tried disabling query rewriting on the "commerce_line_item_table" view, as described here: https://www.drupal.org/node/1333174#comment-6063012
This also worked.

I'm using commerce billy for generating invoice pdf, which I then attach to an email using Mimemail. I made a small module, which provides a rule for saving the PDF on server. In my case, the rule is called on a callback from the payment provider, so no user is logged in at the moment the PDF is generated for an email. As I don't want my module to require that the "commerce_line_item_table" view is altered, I'm sticking to changing the user

Disabling SQL rewrite for the view "commerce_line_item_table" helps.

Tanks seycom, the solution #34 is ok for me :)

Unbelievable this workaround is all that is needed to resolve it.

I've fought this issue for 3 years on one of my sites and just a few months back switched over to the "Messages" approach to emails, only to be disappointed that "Line Item Order Tokens" still didn't work.

I guess I never prayed the right keywords to the search engine gods to land me here.

All because of a security check that was never originally worked out.

Disable SQL Rewriting for the win.

Thanks @gabrielcardon and everyone else who mentioned the sql rewrite trick!