Commerce Line Item Anonymous Access Permissions

I don't believe there's a core issue here; it sounds like the Token that module is using to embed the View output just isn't sufficient. Anonymous users' access control to order / line item information is governed by their session - if you can view it from the order history page (which you can), then there must be some other aspect of the display context in Commerce Invoice Receipt that's keeping them from rendering. Perhaps the session information just isn't available when the e-mail is generated.

fwiw, the line items token that comes from the Entity Field module isn't tested or supported by Commerce, and it sounds like it just may not work. If Invoice Receipt is depending on it, then let's take care of it there.

See commerce_line_item_access() and commerce_cart_commerce_entity_access_condition_commerce_order_alter().

Paypal sand box makes my line-items lost from sale emailing notification.

In order to have access to the line items when sending a mail to an anonymous customer who has just buy something, I added the anonymous user the right to see his own orders and his own any type orders. (as willieseabrook just wrote)

Then when I use the 'Example-payement' payement method I get full access to the line items from the rules making notification email to anonymous buyer without any trouble.

But when I switch to the 'Paypal WPS' payement method (with sand box) I lost this access to the line items from these rules. I can't understand why?

Is there new rights to configure?

Is there a redirection problem when going back from Paypal sand box?

The paiements are working but the mail apear to be suddendtly poor because he can't find line item elements any more.

Could it be just a Sand box' issue that disappear in live?

I'd appreciate any help in this.

Claude

Suite...

Found here some clue: http://drupal.org/node/1333174

But ...

I tried: 1- Administration » Store » Configuration » Order settings » Manage display

...and make sure that "line items" is not hidden for the "Invoice/Receipt" display type. For me all fields were hidden by default.

-> didn't work for me

I tried: 2- For me, giving the anonymous user 'View own orders of any type' permission didn't work, but by editing the commerce_line_item_table view and disabling SQL Query Rewriting under Advanced -> Settings I got it to work... for a while. Then it stopped working, and I haven't yet pinned down what changed in the meantime to make it stop.

-> It works but a got a security warnings messages in the admin GUI when I checked this option related to node access issues.

The message: AVERTISSEMENT : la désactivation de la réécriture SQL signifie que la sécurité des accès aux nœuds est désactivée. Si votre vue est mal configurée, cela pourrait permettre aux utilisateurs de voir des données qu'ils ne devraient pas voir. Veuillez n'utiliser cette option que si vous comprenez et acceptez ce risque de sécurité.

Then does anybody knows other solution to this than the two here above?

Claude

i actually found the issues

For me, giving the anonymous user 'View own orders of any type' permission didn't work, but by editing the commerce_line_item_table view and disabling SQL Query Rewriting under Advanced -> Settings I got it to work... for a while. Then it stopped working, and I haven't yet pinned down what changed in the meantime to make it stop.

This worked for me.

I have also found that disabling SQL Query Rewriting for the commerce_line_item_table view works, but I'm concerned about security consequences of this. Anybody have insight?

I have also found that disabling SQL Query Rewriting for the commerce_line_item_table view works. I get that it's a security risk, the problem is in third party modules, not in commerce module I think. But there should be a way how you can pass the order information to anonymous users as well, the simplest solution would be through some kind of a hash.

Check "View own orders of any type" or disabling SQL Query Rewriting for the commerce_line_item_table view not work for me, any other help?

Disable SQL Query worked for me.
If the view is only called up through the code, then the risk may be acceptable. If the view, however, ever becomes accessible by path/url, then this might indeed be a huge security risk.
Either way, this is a really bad workaround and a better solution should exist.

We're having the same problem. Any news on this issue?

Here is the solution we're looking into. Any feedback is welcome...

1- In the message template located here:
/en/admin/structure/messages/manage/commerce_order_order_confirmation

Replace "!order-summary" with "!order-summary2"

2 : add new tag replacement in your module as shown below
Inside your own patching module (we called commerce_helper)

function commerce_helper_message_presave($message) {
  if (!empty($message->mid) || $message->type != 'commerce_order_order_confirmation') {
    return;
  }
 
  $message->arguments['!order-summary2'] = array(
    'callback' => 'commerce_helper_order_summary',
    'pass message' => TRUE,
  );
}
 

3-Then in the same module make preview as order user, and restore the old user at end.

function commerce_helper_order_summary(Message $message) {
  $wrapper = entity_metadata_wrapper('message', $message);
  $old_user = NULL;
  if(user_is_anonymous()) {
  $order = commerce_order_load($wrapper->message_commerce_order->getIdentifier());
  $old_user = $GLOBALS['user'];
  $GLOBALS['user'] = user_load($order->uid);
  }
  $view = views_get_view('commerce_cart_summary');
  $view->set_arguments(array($wrapper->message_commerce_order->getIdentifier()));
  $view->hide_admin_links = TRUE;
  $html = $view->preview();
  if(isset($old_user)) {
  $GLOBALS['user'] = $old_user;
  }
  return $html;
}

As stated, any feedback is welcome.

please check if this is in any way related to https://www.drupal.org/node/1460964 for you

Same problem here. any updated better way of doing this?

I had the same problem with anonymous orders. The Accountno in the invoice is 0 and no line items.
I solved it by changing 2 functions.
The change is: test if the user is anonymous. If so, get the e-mailaddress from the order, get the userid and use this id in the order.

function commerce_invoice_receipt_view_print(...):
after:
if (module_exists('views_ui')) {
views_ui_contextual_links_suppress(TRUE);
}

if (!$order->uid && $order->mail) {
$account = user_load_by_mail($order->mail);
if (isset($account->uid)) {
$order->uid = $account->uid;
}
}

The same in function commerce_invoice_receipt_mail(...):
after:
if (module_exists('views_ui')) {
views_ui_contextual_links_suppress(TRUE);
}

if (!$params['order']->uid && $params['order']->mail) {
$account = user_load_by_mail($params['order']->mail);
if (isset($account->uid)) {
$params['order']->uid = $account->uid;
}
}

This patch switches to the order's user upon sending mail when the current is user anonymous and the order's user is not anonymous.
This at least fixes the issue for me, as I don't allow anonymous checkout on the site I have this issue on.

I'm not sure what we should need to do for anonymous checkout. Perhaps temporary switch to user 1?