I am writing a module called Commerce Product Add-on that puts products as add-ons on the Add to Cart forms of other products. It works for the most part.

Part of what it does is add another view mode for product entities. This view mode is used for this context.

We call this to add the displayed product to the form.
entity_view('commerce_product', array($product_add_on->product_id => $product_add_on),'commerce_pado');

However, for people without the View Product permissions, like anonymous users it throws an error.

Notice: Undefined index: path in template_preprocess_entity() (line 1020 of /Users/mattrobison/Documents/Projects/memberdrop/sites/all/modules/entity/entity.module).
Notice: Undefined index: path in template_preprocess_entity() (line 1028 of /Users/mattrobison/Documents/Projects/memberdrop/sites/all/modules/entity/entity.module).

Now, this might be related to the entity api module. Not sure exactly.

But is there a way to bypass the access permission for just this view mode? Because the error goes away when I set the permission I. I'd rather not make that a requirement. Just asking for insight.

Thanks!

CommentFileSizeAuthor
#1 1929630-1.product_view_access.patch1.41 KBrszrama
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rszrama’s picture

Version: 7.x-1.5 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
1.41 KB

This is an issue with the Entity API in that because you aren't passing in a page variable, it's attempting to detect it by assuming any entity it tries to process must have its own URI. This isn't the case for line items, for example, which will never return an entity URI - but there's a related issue in Commerce where the fact that we rely on NULL return values may be inconsistent with the core expectation of that API function.

What you can do to avoid the index error is to simply pass in the page variable as FALSE - basically telling Entity API that you're not trying to render the product data on the entity's canonical page like you would a node at node/*. Do this by setting $variables['elements']['#page'] = FALSE. That should take care of it.

However, I have detected a deeper issue that is a bug in Commerce but thankfully would be mitigated by the menu access system. Right now, our implementation of the URI callback will return a path to admin/store/products/%commerce_product if a user has view permissions on the product. A lot of people, to get around difficulties with Views relationships, do use view permissions for products to make certain relationships work. In that case, entity_uri() would return an admin URI to someone who isn't supposed to see that page.

Fortunately, our menu access system uses the appropriate update permission check instead of the view permission check used in our callback. Even if someone had a link to the admin page, clicking it would generate a 403. Since we haven't heard of this yet, I'm guessing no one has used the permission and enabled a configuration that resulted in people seeing inappropriate links. Or maybe since the menu router knew a user wouldn't be able to click it, the link was simply disabled. I think that's how user profiles work, though that may be some custom behavior.

In any event, here's a patch for the test bot to chew on, and here's the related issue: #1392654: Commerce can return invalid return values for uri callbacks.

rszrama’s picture

Status: Needs review » Fixed

Marking fix for the secondary issue; NULL URL follow-up can happen in the linked issue methinks.

jazzdrive3’s picture

Thanks for the insight. I actually need to set it to TRUE, so the title isn't rendered. Very confusing. But even if I set it to false, it still throws an undefined index error for anonymous users.

Status: Fixed » Closed (fixed)

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