Views Product relationship permissions are too strict

As a follow-up, I just created another similar view for admins. User 2 is an admin, with permission to view any products of certain types.

Similar to in the original issue report, this user was unable to see the orders for other users and their products until I granted this user "view all products of any type" permission, even though the user *did* have permission to view the products that were actually being displayed, through a more specific "view any (particular product type) product" permission.

I am reopening this issue temporarily since you asked for feedback and that other one has about 100 irrelevant comments on it and no summary, and searching did not find the possible other issue that you mentioned.

So here is some more information about the use case behind this issue.

I'm helping to build build a site with several different roles, where certain users create their own unique products, and then they create orders on the site in order to transact business related to those products. There are no nodes involved. Here is the setup:
- Role A can create products of type A (representing a particular instance of a training class of type A) and view/purchase only their own products. Once a product is purchased, its status is set to 0 so it cannot be purchased again. (The orders are for ordering student certificates.)
- Role B can create products of type B and view/purchase only their own.
- Role C is an admin for products of A/B, but not for other types of products. They should be able to view any products of type A and B regardless of who created them.
- Workflow: Roles A and B first create their custom products several weeks before they teach a class. Then they come back to the site after the class is taught, fill in some more details, and place an order for certificates for the students. Role C reviews the orders, prints the certificates, and sends them to the trainers.
- So roles A and B need to be able to see lists of the products they've created but not yet purchased, and also their orders; the order view needs some information from the product being ordered (the class type and the class dates) in order to be useful.
- Role C also needs to be able to list the products created by all users that haven't yet been ordered, and list the orders from all users (with information from the products in the view) in order to select orders to batch print certificates, etc.

So... That is why we need the permissions to work correctly on the Views that have a base table of orders and a relationship to Products. The product-only views are working correctly for all users. But since the order-relationship-product views are not obeying the permissions, I have a problem.

To make it work, I've had to grant "view own products of any type" permission to roles A and B, which is not a huge problem since they only have permission to create products of the one type anyway. But I've also had to grant "view all products of all types" to role C, which could be an issue if we have a different subset of products with different administrators. So that permission is more permissive than I really wanted to do.

So... I don't see why it would be a problem for the views Product relationship to follow the same permissions as the base Product views already are following, and I don't see why it isn't a bug if this is not the case?

I looked at Views, and given that this relationship is just using the default relationship handler, the only access check that is being done is adding any query tags that the base table has specified to the query. In this case, that means adding the query tag 'commerce_product_access' to the query.

So then I looked at the commerce product module, and when this query tag is encountered, it is calling the Commerce core commerce_entity_access_query_alter() function to actually alter the query.

So it looks like that function is not doing the right thing for my queries, because even though there is definite code in there that seems to be checking for the user-specific "view own" types of permissions, in practice these permissions are not being obeyed for the example I gave above. I am pretty sure the bug must be there since that is where the query is being altered, and the entries only vanish for queries when the product relationship is added.

Oh, I think I see what the problem is. That function is assuming that the base table of the view is the one that needs to have conditions applied. But I am using several relationships: Orders -> relationship to Line Items -> relationship to Products.

So when this function is called, it is checking user_access based on the commerce_product "view any commerce_product entity of bundle X" and "view own commerce_product entity of bundle X" permissions, but then it is applying the query conditions to $base_table, which is the Orders table in this View, and saying $base_table.bundle == X, which is never going to be TRUE, hence the vanishing view.

In other words, this query alter is not doing the right thing. It needs to search through the tables in $query and apply the permissions to the table that matches the entity type, not just blindly apply them to the base table of the query.

Either that or the functions that call this Commerce core query alter function need to do that search, and pass in $base_table as an argument to the function.

But the way the query alter is being done now is not correct.

I have some code in the API module that does a similar thing to what you need to do. Basically, when you have an access query alter, you need to make sure that you are using the right table alias because someone could have multiple copies of the table you are interested in, in any query (especially if Views is involved in making the query). You need to do something like this:

function api_query_node_access_alter($query) {
...

  // Find all instances of the 'node' table, and make sure they exclude API
  // nodes.
  $tables = $query->getTables();
  foreach ($tables as $alias => $table_info) {
    if (is_array($table_info) && isset($table_info['table']) && $table_info['table'] == 'node') {
      // substitute your query conditions for these couple of lines!
      $or = db_or()
        ->isNull($alias . '.type')
        ->condition($alias . '.type', 'api', '<>');
      $query->condition($or);
    }
  }
}

Or see how Core does it for node access tables, which is even more complicated:
https://api.drupal.org/api/drupal/modules!node!node.module/function/_nod...

Basically, after determining that {node} is the table it needs to check access on, it does a similar loop to what I put in that previous comment, to find all instances of this table in the query and alter all of the aliases with the right conditions.

Whereas the function in commerce.module just assumes the first table is the one that needs the conditions, which is likely not to be the case in Views with Relationships.

I just checked the repository on drupal.org and I'm not seeing any such commit, so unless you have a different repo somewhere else, I guess not! I also had searched for other issues before I created this one, and didn't find anything that I thought was a duplicate except perhaps
#1276450: Views results empty for unprivileged user when using Relationship: Content: Referenced Product
which we've now agreed isn't a duplicate.