Table with line items not included in the e-mail sent to regular user

The table comes from a view, so maybe that view is not outputting anything for some reason...

I ran into this issue with !order-summary being blank when using commerce_paypal as a payment method. After a bit of digging around, I narrowed it down to commerce_message_order_summary(). PayPal calls the site via the IPN (which runs with anonymous user access) and doesn't have access to view the order.

The view needs to be run with more privileges. Do you think implementing the solution from http://drupal.org/node/1793862 would work?

I can confirm the same issue exactly as OP.

Which view is it that feeds the !order-summary ?

I believe it's the commerce_cart_summary view getting pulled in by commerce_message_order_summary(). Tested the view with "View any Order order" permission enabled for anonymous users and the view displays correctly in the email when triggered by IPN.

Thanks, well I think that sort of makes it hard to pin down where the bug really is, commerce message cant control this, and it cant be changed by the paypal module. I think the devs need to see this issue in a broader context perhaps?

i don't know if the following indication is interesting to find the bug ... anyway :

my site is on test and i have 3 possibilities for "payment" :
- payment sample
- Kickstart example payment
- payment module (payzen)

the two first call the "field_revision_message_text" table, and i get my line items in mails,
the third one calls the "field_data_message_text" table, and i don't get them
(i found it because i did translate the "message_text_value" of the "field_data_message_text" table and not the other one)

and if i understand the sql of the "field_data_message_text" table :
`revision_id` int(10) unsigned DEFAULT NULL COMMENT 'The entity revision id this data is attached to, or NULL if the entity type is not versioned',
as i have "9" in the field "revision_id" of the "field_data_message_text" table, the message which should be called by my payment module is the one of the "field_revision_message_text" table

I made a patch, it's probably the wrong way to do this and might open up security vulnerabilities, but it works for me. YMMV. (If someone knows a better way to pass a user to generate a view or bypass the permissions, i'd love to hear about it).

The main issue is indeed that some payment providers (Ogone in my case) hit a backend page to confirm payment, which is run as anonymous/guest. Naturally Drupal doesn't allow just anyone to see orders (well, i guess you could enable it for anonymous, but it's probably not a great idea), so the view is rendered as an empty div. This patch temporarily sets the user as admin, renders the view and drops down to the previous user again.

I coudn't reproduce this. Could you provide more info about your Commerce systems.

Some things/questions about this:
1. First, how you get the line items "table" in messages.
This module doesn't use it. This is added in the Commerce Kickstart Order module - maybe this is the real isse : missing "!order-summary".

2. Do you have "view own orders" permission set for ordinary users?

3. Does the Mimemail HTML emailing works in other cases?

4. Do you have same problem within a Commerce Kickstart install? Could you provide the differences between a Commerce Kickstart system and yours.
for example the Kickstart uses:
- Mimemail for HTML email, using "Full HTML" text format
- Commerce Kickstart Order alter the message for Order confirmation, adding profile Address data and "!order-summary" - commerce_cart_summary View which includes the line items
- "View own orders of any type" and "Edit Mime Mail user settings" for all users Roles.

what about "Plaintext email only" Emails settings for the "other/ordinary" user account?

No, !order-summary is provided by commerce_message.

i meant that "!order-summary" is not present in the "commerce_order_order_confirmation" message type definition.
http://drupalcode.org/project/commerce_message.git/blob/refs/heads/7.x-1...

1) the !order-summary token is used by http://drupalcode.org/project/commerce_message.git/blob/refs/heads/7.x-1... (line 59)
2) users can see their own orders, anonymous can't see any orders for obvious reasons
3) mimemail works normally, afaik (account mails get sent out normally, etc)
4) have not tried using kickstart, but i'm not sure how you can easily emulate an external payment provider that works as described in post #9)

the key issue (IMHO) is that some payment providers (like Ogone, maybe stuff like Paypal works the same way) need to hit a backend page as 'anonymous', which has no rights to see the order. My patch works around this, but i don't like it at all. Hopefully someone that knows more about this stuff knows a safer fix (it would already be a massive improvement if it only elevated uid to the user that made the order instead of uid 1).

I can confirm that order notification emails do not include line items from the !order-summary token when using Paypal Payments Standard for processing. I'm using Commerce Kickstart 7.x-2.0 so it's possible this has been fixed in a newer version.

I'll post back when I've updated to the latest release.

Same problem here. Anything new about this?

Well, in case it helps the experts, I am not one of them, I receive a perfect email when I buy something as administrator using PayPal Sandbox, but the !order-summary token is not rendered at all when I buy something either as anonymous or registered user. I am using Commerce Kickstart 7.x-2.9

Update: Applying fix #5 as discussed here: https://drupal.org/node/1276450 seems to work so far...

#9 patch is working.

I think this problem is the email formatting and it only occurs for anonymous users. I came across the problem building a shop which does not let visitors create user profiles.

I'm having the same issue after following the steps in #2094739: Does not work for anonymous users out of the box (some rules assume at least auth. user) in an attempt to send the email to anonymous users.

Could this be a PayPal issue?

I noticed similar issues in the Commerce Invoice receipt module (drupal.org/node/1811972).
Also, might this issue be relevant? https://drupal.org/node/1301570

The SQL workaround seems to work for some people, but only for a while. It worked for me once for one e-mail but has stopped working since.

After looking at these:
http://www.zen-cart.com/showthread.php?171931-PayPal-IPN-Item-Details-in...
http://drupalcode.org/project/commerce_paypal_ec.git/commit/5ad1d21

Has anyone tried whether express checkout behaves any differently?

I had no success with getting line items to show in orders using commerce message and paypal (paypal is supposedly having the anonymous user problem) neither disabling SQL rewrite nor giving annonymous permission to view any product does the trick for me. Do I need to look at the core issue or at #9 ?

Hiding all fields except line items in the order display mode just got me the correct mail.
Will try if it works reliably
EDIT:
no cigar, i got the correct email with lineitem table once, but that was it.

When I set this up fresh i get the complete order info in the first mail i get. Subsequent orders aren't included anymore

For the first order for some reason the owner is maintained when setting the order to completed. After that paypal seems to use anonymous

I had a custom rule changing the order state.
After i changed that rules weight to 10 SQL rewrite check box does the trick it seems

I am terribly sorry for all the false positives.
seems every time it worked I had the cart open in another tab. Which seems to have circumvented the permission issue

I had this happen on a site. I was in IRC discussing with @discipolo.

+++ commerce_message.module (e1be0b8)
@@ -74,11 +74,23 @@
   $view->set_arguments(array($wrapper->message_commerce_order->getIdentifier()));

We have the order loaded...why not user the UID attached to the order? Or do we technically run into the issue that an anonymous order hasn't yet been set to an existing user or their account created?

I have the feeling this might have something to do with https://drupal.org/node/1350264 , but I am not sure.

Since i enabled paypal express checkout module the order info is in the Mails.

I will need to retrace my steps to see what else intervenes. I currently have the patch extending commerce access applied and disabled SQL rewrite .
Will check if those are needed.

I had realised it worked if I clicked on the "return to store" link fast enough.
Since i enabled express checkout the mail is sent only after i click that link.

I don't want to use express checkout and will have to see why simply enabling it changes wps

Still works without disabling SQL rewrite it seems.

Looks like i don't even need express checkout rule active, just enable the module

Just one last piece that I stumbled over https://www.drupal.org/node/1460964

Using Paypal WPS and disabled SQL rewriting in the view solved this issue.

Enabling the Paypal EC module (but not including as a payment option) was not a solution for me as it introduced an addtional problem. I.e. "when completing the checkout process" doesn't trigger unless a user returns to the website from PP.

#9 patch worked for me!

Also ran into this issue where !order-summary returns empty for anonymous users.

This issue occurs with:
- commerce_check-7.x-1.0-alpha1.
- commerce_stripe-7.x-1.0-rc6 (with test keys)

No PayPal here.

Patch in #9 works. But as this might open up security vulnerabilities, it would be nice to confirm whether or not this is the case and if it is what can be done about it.

Setting to major as this (complete invoice for anonymous users) is IMHO a must for e-commerce.

Thanks @jonne.freebase and thanks everyone for your help on this.

Did a little digging and found this: Safely Impersonating Another User.

The recommended/safe way to do this in D7 is as follows.

  global $user;
  $original_user = $user;
  $old_state = drupal_save_session();
  drupal_save_session(FALSE);
  $user = user_load(1);
  // Take your action here where you pretend to be the user with UID = 1 (typically the admin user on a site)
  // If your code fails, it's not a problem because the session will not be saved
  $user = $original_user;
  drupal_save_session($old_state);
  // From here on the $user is back to normal so it's OK for the session to be saved

And this is exactly how patch in #9 goes about its business. I'm no expert but it appears that this technique is sound and that it does not open up security vulnerabilities.

Does this make sense?

I can confirm that #9 works like a charm...

Confirm that #9 works for me

Confirm #9 works for me.

I had this problem using PayPal WPS, with !order-summary not being populated in the email when returning from the payment on PayPal (but present on the message log).

I applied the patch and tested again and !order-summary was populated in the email.

Realized this never got marked CNR.

Problem persists when message type commerce_order_order_confirmation is cloned...

Aha, this is why cloning the commerce_order_order_confirmation message as e.g. commerce_order_order_confirmation_cloned and then trying to print !order-summary in that new message doesn't work. Look at the second condition.

function commerce_message_message_presave($message) {
  if (!empty($message->mid) || $message->type != 'commerce_order_order_confirmation') {
    return;
  }

  $message->arguments['!order-summary'] = array(
    'callback' => 'commerce_message_order_summary',
    'pass message' => TRUE,
  );
}

The !order-summary token is restricted to only commerce_order_order_confirmation.

My use case is to send different notifications based on payment method e.g. if credit card then message 1 else message 2.

Is there a reason for this restriction? If not, any suggestions as how to best deal with clones of commerce_order_order_confirmation ?

UPDATE - Posts #42 and #43 are NOT related to the present issue.

For a solution to that cloning issue, see !order-summary token not replaced in message types other than "commerce_order_order_confirmation"

After a few hours of head scratching I found this thread and #9 fixed my problem (my payment method is https://www.drupal.org/project/commerce_worldpay )

The patch in #9 works and follows Drupal best practices when impersonating another user per #37. I believe this to be a valid fix and am marking it RTBC. There were some issues with coding standards and messaging, so I cleaned those up.

Comment mistake :)

a simpler way:

• Edit Shopping cart summary view
• Query settings:
• turn on: Disable SQL rewriting

#47 Works great for me. Thank you!!

#47 worked for me as well. Finally I can get rid of the rendered Order entity!

#48 worked for me (thank you adambinkowski :) but is there any security concern?
UPDATE: #48 din't work for me. What really worked for me is bisonbleu's patch at !order-summary token not replaced in message types other than "commerce_order_order_confirmation"

#37 worked for me after some mandrill tweaking, visible here : https://www.drupal.org/node/1333174#comment-10597640

Great work everyone! But HUH this really has security issues, like showing customers the comments from the shop owners about them =:-().

Patch flying in that shows the order summary with permissions of the original order owner, which is the right thing to do (tm).

Please test and RTBC.

Shameless plug: Commerce Message Helper | Drupal.org now also includes this.

@axel.rutz Exactly, that's also what i've been optimizing in my payment checkout completion flow.
Take the user from the order instead of admin, unless this user is still anonymous.
This can be prevented by registering this anonymous user with an authenticated (read: protected) role right before final checkout stage by applying some rule for it.

Thanks for the additional comment on this.
I was aware of the risk but forgot to post it here.

This has still issues when the order owner has changed (created account for anon arder) but is not saved. Saving the order beforehand fixes this too.

#55 looks nice and fixes things. Good solution from my point of view. More feedback for RTBC?

PS: It also works. I tested it of course.

1. +++ b/commerce_message.module
   @@ -74,11 +74,35 @@ function commerce_message_message_presave($message) {
   +  // Assure that the summary view does see the current order and its owner.
   +  $order_wrapper->save();
   

   Why does the order need to be saved? We aren't changing it's values.

2. +++ b/commerce_message.module
   @@ -74,11 +74,35 @@ function commerce_message_message_presave($message) {
   +  // Safely impersonate another user.
   +  global $user;
   +  $original_user = $user;
   +  $old_state = drupal_save_session(FALSE);
   +  $user = $order_owner;
   

   Maybe it would be better if the view took an argument necessary instead of impersonating the user which sounds like a SEC hole waiting to be discovered.

#58:

> Why does the order need to be saved? We aren't changing it's values.
Not us, but in the payment process it may be and usually is.

> Maybe it would be better if the view took an argument
The view is not under our control, and an argument can't change access.

> which sounds like a SEC hole
The order view must be viewed by the order owner. Everything else would open security issues.

axel.rutz #55 patch works great for me, thanks!!

So RTBC as of #60&#57.

I'm curious here

  $view->set_arguments(array($wrapper->message_commerce_order->getIdentifier()));
  $view->hide_admin_links = TRUE;
  return $view->preview();

Why don't we just disable SQL rewriting or whatever instead of hijacking the user session? I'd like to see that tried. I'll see if I can give it a whirl

+++ b/commerce_message.module
@@ -74,11 +74,35 @@ function commerce_message_message_presave($message) {
+  $old_state = drupal_save_session(FALSE);

This will not work, the state passed to the function is returned and not the previous state.
Should be split into 2 calls, one to get old state and then change it afterwards.
Have created a crude modification of the previous patch that should fix this issue.

that said an approach where disabling user authentication on the view query would be a safer approach than hijacking the user.

This is the approach we should be taking, in my opinion. I'm going to write tests. The issue here is some of the quirks of the entity access items that live within Commerce and the Entity API. The same reason a customer might not be able to see products, because each entity has a "view any" and "view own" permission, the former flagged. This will bypass the query tags and only use the View's permissions.

Putting to needs work as I'm going to write a test for this.

Ok! Here's two patches. One proving that it will fail without the SQL rewrite and that this entire thread is valid. Then the other will pass,showing the solution is simply the sql rewrite option and not hijacking current user session.

Awesome! I like this much better than juggling the global user.

Fixed. SQL Rewrite is about the only way to work around this issue, see even the discussion here: #1276450: Views results empty for unprivileged user when using Relationship: Content: Referenced Product.

As stated, if you disable rewriting you completely disable access control which opens serious security issues. Just to make it explicit.

completely disable access control which opens serious security issues

And automatically loading a user's session to bypass that security is better? It's the same method, but in this we do not hijack any sessions or impersonate any users.

Follow up: If this is an issue then we should fully remove the token. It's not provided by default in the messages. I believe CK2 just adds it, then as users please. This is based on #71's comment.

I agree with #72.

for what it's worth, I found this comment by Dave Reid on Stackexchange:

The drupal_cron_run() function gives a perfect example for exactly this [programmatically impersonating another user], since it changes the current user to anonymous whenever cron is run, then switches back after it is done.

I would like to add #55 seemed to work nice apart from the fact that it results in an error when trying to view the messages overview

EntityMetadataWrapperException: Unable to get the data property format as the parent data structure is not set. EntityStructureWrapper->getPropertyValue() (line 438

#65 Seems to do the trick without throwing error at the messages overview.

@#77: a full backtrace would help with this (use pbt module). This *may* happen for orders without owner though, but those are invalid and the real bug reason though.

For anyone who also prefers #55 "impersonate" over #69 "switch off access control", here's the rebased patch flying in.

As of January 2017 This is fixed with commerce message 7.x-1.0-rc5 https://www.drupal.org/project/commerce_message/releases/7.x-1.0-rc5

No more hustle with Bugs. You can let go the patches now