Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
A view with a Content: Referenced Product Relationship (Drupal Commerce) shows the desired output of fields for admin, but the output is empty for Anonymous users.
When I delete the relationship, the view's content does show for Anonymous.
Here's the view:
$view = new view;
$view->name = 'test_catalog';
$view->description = 'A view that lists currently available tests.';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'test Catalog';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'tests';
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['query']['options']['query_comment'] = FALSE;
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'some';
$handler->display->display_options['pager']['options']['items_per_page'] = '9';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';
/* Relationship: Content: Referenced product */
$handler->display->display_options['relationships']['field_product_ref_product_id']['id'] = 'field_product_ref_product_id';
$handler->display->display_options['relationships']['field_product_ref_product_id']['table'] = 'field_data_field_product_ref';
$handler->display->display_options['relationships']['field_product_ref_product_id']['field'] = 'field_product_ref_product_id';
$handler->display->display_options['relationships']['field_product_ref_product_id']['label'] = 'Product Reference';
$handler->display->display_options['relationships']['field_product_ref_product_id']['required'] = 1;
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 0;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 0;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Field: Field: Image */
$handler->display->display_options['fields']['field_image']['id'] = 'field_image';
$handler->display->display_options['fields']['field_image']['table'] = 'field_data_field_image';
$handler->display->display_options['fields']['field_image']['field'] = 'field_image';
$handler->display->display_options['fields']['field_image']['relationship'] = 'field_product_ref_product_id';
$handler->display->display_options['fields']['field_image']['label'] = '';
$handler->display->display_options['fields']['field_image']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['path'] = '[view_node]';
$handler->display->display_options['fields']['field_image']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['external'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['replace_spaces'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['trim_whitespace'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['alt'] = '[field_image-alt]';
$handler->display->display_options['fields']['field_image']['alter']['nl2br'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['field_image']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['field_image']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['trim'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['html'] = 0;
$handler->display->display_options['fields']['field_image']['element_label_colon'] = FALSE;
$handler->display->display_options['fields']['field_image']['element_default_classes'] = 1;
$handler->display->display_options['fields']['field_image']['hide_empty'] = 0;
$handler->display->display_options['fields']['field_image']['empty_zero'] = 0;
$handler->display->display_options['fields']['field_image']['hide_alter_empty'] = 0;
$handler->display->display_options['fields']['field_image']['click_sort_column'] = 'fid';
$handler->display->display_options['fields']['field_image']['settings'] = array(
'image_style' => 'width-220',
'image_link' => '',
);
$handler->display->display_options['fields']['field_image']['field_api_classes'] = 0;
/* Sort criterion: Content: Title */
$handler->display->display_options['sorts']['title']['id'] = 'title';
$handler->display->display_options['sorts']['title']['table'] = 'node';
$handler->display->display_options['sorts']['title']['field'] = 'title';
$handler->display->display_options['sorts']['title']['order'] = 'DESC';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 0;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
'test_display' => 'test_display',
);
/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'tests';
$handler->display->display_options['menu']['type'] = 'normal';
$handler->display->display_options['menu']['title'] = 'Tests';
$handler->display->display_options['menu']['weight'] = '0';
$handler->display->display_options['menu']['name'] = 'main-menu';
Comment | File | Size | Author |
---|---|---|---|
#167 | commerce-fix_access_for_rows_w_null_in_left_join-1276450-167.patch | 2.5 KB | pingwin4eg |
#124 | commerce.cart_.1276450-124.patch | 1.38 KB | freelock |
#2 | views_productdisplay_baskets.txt | 42.84 KB | aharvie |
#2 | views_bug_loggedin.png | 34.04 KB | aharvie |
#2 | views_bug_notloggedin.png | 23.38 KB | aharvie |
Comments
Comment #1
rucx CreditAttribution: rucx commentedfixed with latest dev's of views and commerce but now getting the https://drupal.org/node/1265152 error
Comment #2
aharvie CreditAttribution: aharvie commentedI'm having a similar problem. There seems to be a difference in that it doesn't make a difference whether I remove the relationship or not. [EDIT]: I realized I created my view directly displaying the product type instead of their display nodes. I recreated the view properly, and now I see the same behaviour with the relationship removed. Updating to the dev versions hasn't helped though.[/EDIT] Anonymous users can't see views displaying products. I've tried using the most recent dev versions of Commerce and Views available on their project pages, but still no results.
Using a clean install of Commerce (no kickstarter), Views 7.x-3.0-rc1, Commerce 7.x-1.0. I've attached a txt with the views export and a couple of screenshots.
Comment #3
rennevat CreditAttribution: rennevat commentedExperiencing same issue for anonymous users (Views 7.x-3.x-dev) when using Referenced Product (Commerce 7.x-1.x-dev). Other content views functioning properly. Attempted rebuilding permissions, flushing cache, modifying Views access by Role then Permission but no success. Subscribing.
Comment #4
rennevat CreditAttribution: rennevat commentedImplementing the suggestion in this post http://drupal.org/node/1276900#comment-4980066 to all the catalog views now allows anonymous users to view the product catalog again.
Comment #5
GiorgosK#1 comment on the mentioned issue above solves this
but can someone confirm that "Disable Query Rewritting" does not create other problems ?
my view was working fine until I updated views to dev version 10 days ago
EDIT:
this is the warning in the query settings
Comment #6
1kenthomas CreditAttribution: 1kenthomas commentedHmm. I *think* this is the issue I'm having, so I'll stick to adding here.
I must grant (at least) the following permission, for roles to see products in display nodes in views:
even if the role has "access all content" perms.
Same issue?
Comment #7
jakonore CreditAttribution: jakonore commented#4 worked for me.
Comment #8
sairanac CreditAttribution: sairanac commentedsubscribe.
Comment #9
laraz CreditAttribution: laraz commented#4 worked for me .
#6 worked for me.
but is the best solution?
Subscribe.
Comment #10
jakonore CreditAttribution: jakonore commented#4 worked for me. Don't want to try #6 since it opens a big security hole in my website. but anyway I don't think #4 is a final solution.
Comment #11
chazsmi CreditAttribution: chazsmi commentedI have the same problem, #4 works for all views except cart #6 works for cart.
This only happened to me after I updated to the latest release of views.
#4, #6 cant be a long term solution to the problem, is there any progress on fixing this?
Comment #12
Zorin 007 CreditAttribution: Zorin 007 commentedHaving the same problem, my view displays ok until I add a relationship ( Drupal Commerce ) , then it no-longer displays for anonymous. #4 works but I agree with #11 we should not close the issue.
Comment #13
rfayIMO this is probably not a bug. We're giving access to products through a view like this, and an anon user doesn't have privileges on them.
The relevant views discussion is in #1222324: Fix query access control on relationships (comments)
Comment #14
rfayI'm going to call this a 1.1 blocker. I'm pretty sure the behavior described here is correct, but it's just appearing strongly in recent views versions.
It's going to break some existing sites with views of nodes that reference products.
At least the release notes need to let people know about this (assuming it is in fact a change).
Comment #15
rfayThis is critical, as it breaks an enormous number of existing installs. It is in fact a result of #1222324: Fix query access control on relationships (comments) and I'm not sure what we should do about it. There are piles of views that depend on the old behavior.
Comment #16
fearlsgroove CreditAttribution: fearlsgroove commentedI think the existing behavior is probably a bug. If a user doesn't have rights to view product entities, that user should not be able to view product entities via a relationship. I'm not sure exactly what the state of the views fix is. I'm using the current-dev and do have the issue, but not the issue where view cart is completely gone. Not sure exactly what got rolled back.
Can anyone explain the security implications of the view product permission? Perhaps viewing the products via the admin URL? If so maybe products need a separate entity permission that allows them to be viewed as front end objects such as via relationships.
Comment #17
rszrama CreditAttribution: rszrama commentedRandy, can you clarify for me how the other issue interacts with this one? I don't know the history behind it, but it looks like you bumped this to critical even though the problem is a bug in Views itself. Is the issue jus with the Views 3.0-rc3 release, or is it still just in Views dev?
Comment #18
rfay@rszrama, this one is certainly a duplicate of #1222324: Fix query access control on relationships (comments), which is apparently not actually a bug, but a feature. It's a *new* feature, though, and it dramatically affects what we've been telling people to do for a long time.
Essentially, all the sitebuilders who have been building customer-facing views of product display nodes using relationships to products are going to be completely broken. We probably need a new permission that is not security sensitive that allows end-users including anon to view products somehow (avoiding whatever the security problem is with this).
Comment #19
fearlsgroove CreditAttribution: fearlsgroove commentedThis issue is back to the state of the original report using commerce -dev and views -dev -- anonymous users can't see their cart.
Comment #20
rfayI don't think it's changed. The views folks would say we've been relying on a bug. And this isn't just anon users, IMO, it's any user that doesn't have "access products" permission. Or at least it should be.
Comment #21
tormiRyan, Randy - what is the recommended quickfix when having this issue? Should I give "View any Product product" privilege to anon users?
Comment #22
rfay#5 has the quick fix.
Comment #23
fearlsgroove CreditAttribution: fearlsgroove commentedI took a quick look at the permissions on product entities. If I enable view any product type for anon users, they are still unable to access products at admin/commerce/products/1234, but the access control on the menu item itself is just commerce_product_access, which would allow it. I'm assuming anon users are bumped out of anything below admin/* by parent menu items. Seems like it might also accidentally allow access to view the entity at other URLs perhaps added by third party modules.
It would be quite straightforward to add a new permission to "view products of any type in queries" and change
commerce_product_query_commerce_product_access_alter()
to check that permission in addition to the built in entity permission, give anon users access by default and add a simple update script.Comment #24
kiwimind CreditAttribution: kiwimind commented#5 does not allow for an anon user to view a cart though. It only allows them to view the products.
Comment #25
graker CreditAttribution: graker commentedI've just checked and #6 fixes the issue and does allow anonymous users to view their carts. At least, for me it does.
Anyways, I have a question of another kind. On permissions page it says that if I give away "View any product of any type" permission, that would be a security issue. But admin pages with enlisted products are still closed for anonymous users. So, what is the danger of giving it away?
Comment #26
Summit CreditAttribution: Summit commentedHi, using #5, but not yet seeing what risk I am having with doing this?
Thanks a lot in advance for your reply!
Greetings, Martijn
Comment #27
benschaaf CreditAttribution: benschaaf commentedI am also using #6 and can confirm it is working. But, I am also concerned about security implications.
Any detail what the implications are or how at risk we are for using this workaround?
Comment #28
kiwimind CreditAttribution: kiwimind commentedI've now extended #5 to include the shopping cart block and summary pages so that an anon user can see the lot. I'm still unsure as to why #6 is deemed unsafe, so will probably stick with applying #5 wherever it's needed for now. Would be interested to learn more.
Comment #29
latulipeblanche CreditAttribution: latulipeblanche commented#5 works for me .
tnx @GiorgosK
Comment #30
AJen CreditAttribution: AJen commented#6 worked for me also.
Just wanted to add: I'm using DC for a clothing store. I need to add the relationship to the shopping cart so that I can include the colour and size of the product in the cart. If I don't do this, it's very confusing as when you select the product colour, click 'add to cart', the product is added to the cart but the screen jumps back to the default colour which would leave the user wondering what colour product they've just added to their cart.
Comment #31
kiwimind CreditAttribution: kiwimind commented@Aussiejen, you can show the attributes in the cart by amending your view. I'm putting together something similar, although it's just sizes. My line items show the size alongside the product.
Comment #32
brunorios1 CreditAttribution: brunorios1 commented@aussiejen
http://drupal.org/project/commerce_product_attributes
Comment #33
AJen CreditAttribution: AJen commentedI have put the attributes in the cart by amending the view, but I did need to implement #6 to make the cart visible to anonymous users
Comment #34
zaglick CreditAttribution: zaglick commented#5 also worked for me to allow non admin users to view the product catalog.
Comment #35
nmc CreditAttribution: nmc commented#5 worked and $6 also worked for me but still haven't seen an answer above as to which is better to do, so... subscribing.
Comment #36
EclipseGc CreditAttribution: EclipseGc commentedOK, after digging through this for a while I've come to a couple of conclusions.
1.) commerce_entity_access_query_alter() seems to be the offending problem here (this plus some clarification on permission usage). Specifically the "'view any ' . $entity_type . ' entity of bundle '" permission doesn't actually work for this because of 2.)
2.) lines 1045-1068 of commerce.module read thus:
And I'm pretty sure that the $really_restricted setting here needs to be moved out of the foreach and instead some sort of static test variable should be added.
3.) Beyond that, the elseif in this code is almost repeated verbatim a few lines later (after the return for $really_restricted is done).
The code in the elseif inside the 2.) snippet seems a little more complete, so I'm confused...
4.) Permission wise, the only place that user_access() against the 'view any ' . $entity_type . ' entity of bundle ' permission is used is in commerce_entity_access_query_alter(). There's enough indirection here that it could be used elsewhere, but I think this permission might be safe at this point to use for fixing this situation if the code in 2.) can be fixed.
I would have attempted this myself, but there's enough going on here and my access to the significant maintainers of commerce is limited enough right now that I decided to just document this and put it on the issue.
Comment #37
mediapal CreditAttribution: mediapal commentedsorry just a mistake
Comment #38
rfayYou'd probably have to say why you assigned it to yourself.
Comment #39
mediapal CreditAttribution: mediapal commented#5 Works good so far. Will this be the final solution?
Kirk
Comment #40
mediapal CreditAttribution: mediapal commentedSorry for bringing this up again.
I´m quite a newbie in Drupal, the "Disable SQL rewriting" option make me confused.
I´m still wondering is this the only handy solution to get product entities visible for anonymous user?
Is or isn´t is a matter of security?
The point is, I´m the one who don´t understand at all.
Kirk
Comment #41
Pomliane CreditAttribution: Pomliane commentedRemoving "1.1 blocker" tag as 1.1 is out since 2011-Nov-29.
Comment #42
mediapal CreditAttribution: mediapal commentedSorry I don´t understand what doe´s it mean:
Removing "1.1 blocker" tag as 1.1 is out since 2011-Nov-29.
Kirk
Comment #43
hmartens CreditAttribution: hmartens commentedI used #5 and it worked... still a bit nervous as to working with "quick fixes" :) but for now it will do.
Thanks for the help...hope to see this "feature" resolved soon :)
Comment #44
ajaysolutions CreditAttribution: ajaysolutions commentedsubscribing
Comment #45
brunorios1 CreditAttribution: brunorios1 commented@ajaysolutions, You don't need to post a comment to "subscribe" any more; there is a "Follow" button in the upper-right corner of the issue page. Thanks!
Comment #46
hmartens CreditAttribution: hmartens commentedI was wondering why he wrote "subscribing" ...I wanted to type "drinking coffee"...but then I got too busy drinking coffee :)
Comment #47
rszrama CreditAttribution: rszrama commentedlol If only we were on Facebook so I could "Like" your comment. ; )
Comment #48
EclipseGc CreditAttribution: EclipseGc commentedI'm sure dww would LOVE that suggestion ;-)
Comment #49
hmartens CreditAttribution: hmartens commentedhmmm...good idea Ryan! Drupal.org should incorporate the 5star rating module or a similarly a "Like" option :)
Comment #50
ajaysolutions CreditAttribution: ajaysolutions commentedoh yeah nice one, I didn't notice that!
Comment #51
rszrama CreditAttribution: rszrama commentedFor a while now there's been a fix in Views (now part of 3.1) and patches by bojanz to attempt a solution in Commerce as well. I'd be interested in seeing if the patch in #1323366: Query access fails in certain cases on post-RC1 Views fixes this for anyone before marking this a duplicate.
Comment #52
aleksandar.boros.gyevi CreditAttribution: aleksandar.boros.gyevi commentedPach fix the problem with relationships Product for me.
But if I add 2 product to 1 product display the product display will be display twice in view list.
Comment #53
hmartens CreditAttribution: hmartens commentedhmmm...with the latest updates it's still a problem...so far the only real "quickfix" is #5 "Disable Query Rewritting"
Comment #54
mediapal CreditAttribution: mediapal commentedYepp same here.
Comment #55
farez CreditAttribution: farez commentedGuys, I recently had to explain to a colleague the implications of disabling SQL rewriting, so I thought it would be useful to share it here. However, can someone who knows SQL rewriting intimately please validate that this is correct?
So my attempt at a layperson's explanation goes like this... feedback please:
Whenever there is access control involved, query rewriting is used. So for example, if you want the results of a view to be filtered by a specific user, or specific role, then query rewriting is used.
This applies when you are relying on Drupal to do the filtering based on user permissions. For example, if in the user permissions you specify that an order can only be viewed by the person who made the order, and then you create a view that lists all orders in the system, the result of the views will contain only orders belonging to the currently logged in user. So, internally, Views goes and gets everyone's orders, then asks Drupal which one of those orders it should display. Drupal then uses the query rewrite to tell Views how to filter the results.
If you turn off query rewriting, Views will not go and ask Drupal to filter the results, and will display everything. Which is probably what you don't want.
But, you can still achieve the same effect by getting Views to take more control of the results, and applying that filtering within Views itself. If you do this, then it doesn't matter whether query rewriting is enabled or now... the View you create wil be doing the filtering based on the rules you give it.
Which is why, in the warning message that comes up in Views when you disable query rewriting, it says:
"This may allow users to see data they should not be able to see if your view is misconfigured"
Note the bold text. Basically, it doesn't say that it will open up a security hole, full stop. It says that it *may* open up a security hole (which allows users to view unauthorised content), if you do not explicitly handle that access control filtering within Views itself.
And disabling the query rewrite only affects that view for which you have disabled it for. It does not mean the whole system now ignores query rewriting.
What I would suggest is:
1. If the info you want to display with Views isn't ultra sensitive (eg if you don't mind one user accidentally seeing another user's orders), then disable it for now while we wait for a fix. But,
2. Make sure you explicitly handle any access control requirements and filtering within the View itself.
Comment #56
hmartens CreditAttribution: hmartens commentedThanks Farez for explaining it. I went ahead and closed my eyes and disabled query SQL :) But now I understand better...strange that such a bug would be open for such a long time without being fixed...but I understand that the maintainers have real lives and real jobs outside of Drupal :)
Hopefully the fix comes before I officially launch my commerce website :)
Comment #57
alayham CreditAttribution: alayham commented#5 solved my problem.
Comment #58
chrissearle CreditAttribution: chrissearle commentedHad to keep rewriting for some other things so had to go with #6.
I've tried to find out what the security risk is - I can't (as anon) seem to get to anything I'm not supposed to.
What are we being warned about there?
Comment #59
Masala CreditAttribution: Masala commented#5 is work. Turns out that the use of unsafe Commerce?
Comment #60
CanOne CreditAttribution: CanOne commented#5
dont work for me
Comment #61
muschpusch CreditAttribution: muschpusch commented@Caone: try to clear your cache it should work
Comment #62
CanOne CreditAttribution: CanOne commentedHm i´m using a new Drupal installation and a View without relationship now.
And its working quite nice at the moment :)
Comment #63
guy_schneerson CreditAttribution: guy_schneerson commentedWe are using the "Disable SQL rewriting", however I can't figure out (and no answer in this issue) what the view product permissions security issue
"Warning: Give to trusted roles only; this permission has security implications." is. And if it is an issue, why a new permission is not created instead of disabling it all together using the "Disable SQL
rewriting".
I also think 'Semantically' that the "view products" permission should be 'true' by default and any security involved should be moved to another permission.
And that not only views use this permission but all other places like the product reference formatter
Comment #64
rfayI basically agree with #63 and think that the essence of this is: Is it a security issue to allow viewing products? "View any product of any type" is the related permission. I suppose there are situations where you would not want this to be possible (not wanting users to discover either deliberately or by accident products that are priced differently? products that are aimed at a different currency or audience?).
IMO if your site does not feel that products should only be displayed under controlled circumstances, then there is actually no security issue here and it's OK to use the technique in #5 .
Comment #65
guy_schneerson CreditAttribution: guy_schneerson commentedthanks @rfay,
I would much prefer to enable the "View any product of any type" then use the "Disable SQL rewriting" as we have no special conditions for products.
We didn't find any security reason why not to. its only that If something does go wrong and and we ignored a security warning...
Sounds to me like this issue can be closed down by rewording the permission description.
Comment #66
esmerel CreditAttribution: esmerel commentedI just used #5 and #6 to get what I needed. It's weird, because another site I have works just fine without this (the changed site is a clone of the original).
I had an issue in views, where I had the two queries (working and non-working): for the curious, the are here: http://drupal.org/files/twoqueries.txt
Comment #67
hmartens CreditAttribution: hmartens commentedI can see this feature of not showing products to anonymous users very helpful if you've got a subscription-based service or sell very kinky stuff but by default I think the concept of an online store is to show your products to anyone.
I'm running a drupal commerce website for a client now for less than a month (20 000 pageviews, 3000 visitors, plenty sales) and have not come across anything that looks suspicious or security holes that I can see so I guess the "Disable SQL Query" warning is perhaps just a fineprint to cover all bases :)
DRUPAL COMMERCE ROCKS!!!
Comment #68
michaellenahan CreditAttribution: michaellenahan commentedThanks, @guy_schneerson #63 #65 and @rfay #64.
In my case, I also don't mind my users having "view any product of any type" permission.
This solution seems more maintainable/future-proof than changing the query option of the view (#5). A future developer (including future-me) may have a hard time debugging a problem with that view!
Comment #69
Anonymous (not verified) CreditAttribution: Anonymous commentedNeither of theabove solutions solved the problem for me.I was able to get node content displaying, but referenced content (such as price, add to cart button) do not display for anon.Edit: facepalm.
Comment #70
trevorkjorlien CreditAttribution: trevorkjorlien commentedI want to make sure my problem applies here, or if I need to look elsewhere for a solution. For those having/had this problem, when trying to add a product to the cart, instead of the cart appearing, did it say instead "Your shopping cart is empty"?
If not, maybe I'm having a different problem.
Comment #71
aidanlis CreditAttribution: aidanlis commented@trevorkjorlien no, that has nothing to do with this. Your problem is probably the session dropping because securepages is not set up properly.
Comment #72
freelockAs posted on #1349080: node_access filters out accessible nodes when node is left joined, I spent some time in a debugger last night and tracked it down to a core bug in Node module, when any node_access is applied to a query with an optional relationship.
I think this is a duplicate of that issue...
Comment #74
ahhao CreditAttribution: ahhao commentedfollowed.
this is a critical issue.
Comment #75
q00p CreditAttribution: q00p commentedSubscribing - critical issue, in regards to permissions.
#4 and #6 work for displaying the view to anonymous users, but on the site I'm building anonymous users should not be allowed to see the the 'Add to Cart' button, for example.
All else in the site 'Add to Cart' is hidden via the Field Permissions module, except in this view which happens to be the main Product Catalog :/
Comment #76
nimzie CreditAttribution: nimzie commentedsubscribing. We just shut off sql rewriting for views currently. A hack would be to override this setting in all views init. Shut off always...
Comment #77
freelockHi,
There's a patch at http://drupal.org/node/1349080#comment-6263068 that should resolve the issue... still working on test cases for this. Does this patch break anything on your sites?
Comment #78
dwatts3624 CreditAttribution: dwatts3624 commentedsubscribing
Comment #79
laoguxintan CreditAttribution: laoguxintan commentedHave the same problem. Hope someone could to solve it.
Comment #80
guy_schneerson CreditAttribution: guy_schneerson commented@dwatts3624 Great tip: you can use the "Follow" button top right of each issue instead of posting a "subscribing" comment.
@laoguxintan - currently two options exist to resolve this issue: The "View any product of any type" permission or in views "Disable SQL rewriting".
See #5 and #6 and throughout the issue comments.
Comment #81
carlosmedinilla CreditAttribution: carlosmedinilla commentedI only wanted to say that the drupal community is wonderful!
Comment #82
Drupa1ish CreditAttribution: Drupa1ish commented+1
Comment #83
emptyvoid CreditAttribution: emptyvoid commentedShould I assume that if I use either option described in comment #80 that I can't conditionally hide specific products from users if they don't hold a selected role?
So because of the rewrite rules in Views 7.x-3.x either users can see all or no products?
Hrumph!
That puts a bug in the ointment.
Comment #84
guy_schneerson CreditAttribution: guy_schneerson commented@emptyvoid if you are talking about the "View any {product bundle} product" permission then the issue is that while views respects this permission other parts of the commerce system don't like the add to cart form.
Comment #85
jday CreditAttribution: jday commentedAnonymous users can NOT add items to their cart!
drupal 7.16
commerce 7.x-1.3
Still no luck, very disheartened on commerce, as this is a show stopper.
Comment #86
rbosscher CreditAttribution: rbosscher commentedI've had the same issue, once.
But it disappeard also. I figured it had to do with the cookie settings.
Could you check that?
Edit: As a matter of fact I still have the issue.
But it only occures on products that are displayed in a block.
Comment #87
Copyfight CreditAttribution: Copyfight commentedSubscribing. 1 year old issue :-(
Comment #88
jday CreditAttribution: jday commentedI'm not finding any instance where adding to cart works for anonymous users whether from a product display page or a product view, it still says the cart is empty.
Comment #89
Summit CreditAttribution: Summit commentedHi, doesn't http://drupal.org/node/1276450#comment-5000178 work for you?
greetings, Martijn
Comment #90
guy_schneerson CreditAttribution: guy_schneerson commented@jday is this a problem with the the view or adding to cart. One way to test is to go to /checkout if you cant access the checkout then the problem is probably with the add to cart and not the cart view.
Comment #91
guy_schneerson CreditAttribution: guy_schneerson commentedJust repeating what I and others have posted before:
I think that the setting the "View any product of any type" is much more sustainable & secure.
The solution should be removing the warning for the permission and changing the default to true for both anonymous & authenticated user.
but that's just my opinion
Comment #92
jday CreditAttribution: jday commented@summit - yes I've checked the 'Disable SQL rewriting ' for all the product and cart views.
@guy_schneerson - I've given anonymous users the 'view any product' permission, and anonymous users can see all products (pages and views) and they can see the add to cart button, but clicking 'add to cart' does not actually create a cart, although the message is displayed that it has been added to the cart. If I try to go to checkout it says the cart is empty.
Comment #93
pedrorocha CreditAttribution: pedrorocha commentedI tried all the suggestions here and none worked. I tried with the latest versions of Commerce, Views, even with -dev. I understood that it isn't a simple question, but it's sad to see a basic feature for e-commerce sites, anonymous checkout, not working with Drupal Commerce. This sounds as a critical issue to me.
What can we do to solve it? Does anybody knows a way to fix it "consistently", so that no one else face the problem again, but maybe doesn't have time to implement it? What about collecting money with Chipin, so that someone could invest time in this?
@rszrama, i think that we, as a community, need to solve questions like this without asking help for companies, but this issue isn't a priority for Commerce Guys?
Comment #94
Summit CreditAttribution: Summit commentedHi mmm And is it also not working in a clean Drupal with clean latest commerce? Commerce Kickstart?
I find it curious never experienced this behavior...
greetings, Martijn
Comment #95
guy_schneerson CreditAttribution: guy_schneerson commented@pedrorocha, you should give some details about your problem covering whats installed and configuration.
As far as I know this issue has two solutions to the problem and both worked on every commerce site I was involved with.
Comment #96
pedrorocha CreditAttribution: pedrorocha commentedI have Commerce Kickstart 2 beta2. I tried to update modules to see if it solves the problem, so now i'm with CK2, but with some modules updated(Commerce and Views are the latest version now)
I made 2 sites with Commerce, without further problems, but this one is the first with CK2. The 2 first was with Commerce alone and with CK1.
Comment #97
rszrama CreditAttribution: rszrama commented@pedrorocha If this actually prevented anonymous checkout for working, you can bet I wouldn't have had any intermediate releases until it was fixed. Unfortunately, we don't have unlimited resources to put on every bug report, and I've had to leave this one open since there are suggestions above that have worked for other people.
As soon as we can fix it for a release, you can bet this issue will be updated (so keep following : ), but it would be just as great for someone who's being blocked by this issue to post a fix (it hasn't affected us on any of our sites yet).
Comment #98
bojanz CreditAttribution: bojanz commentedThere is nothing to fix here.
We added a workaround for the original issue when it was first reported. What remains is a support request.
If you're displaying fields from a related entity (product in this case), you need to have access to view that entity.
This means that you need to grant users the "view any product of any type privilege" permission.
It has a security warning, which is a mistake on our part, and the warning should be removed.
Kickstart v2 doesn't have this problem because it doesn't show fields from the related entities, it renders the complete related entity in a view mode instead.
(So it's the complete rendered product in a "product in cart" view mode, instead of a relationship to products with a field pulled that way).
Leaving the issue open for now so that we can do a final confirmation before release.
Comment #99
rbosscher CreditAttribution: rbosscher commentedAs I mentioned in #86 I've experienced the same problem. But then only in a view block.
I had this view enabled with a global filter: random. By removing that filter my anonymous customers were able again to put the items of that view in to their cart.
Not sure this is the same issue, but maybe it helps.
Comment #100
Tab10id CreditAttribution: Tab10id commentedhttp://drupal.org/node/1420034 problem with Global Random in this issue.
Comment #101
freelockHi,
As I mentioned in #77, I believe this is a duplicate of #1349080: node_access filters out accessible nodes when node is left joined . I've had a ton of other things on my plate, but I did finally get a test case out for this core bug, for D8. However, my D8 patch does not work correctly -- haven't had time to dig into how to extend the joined table with the proper sql. Anybody intimately familiar with SelectQuery objects, I could use some help...
The issue is not with Commerce. It's a node access issue, and it's triggered when you use a Views Relationship with a node access module (such as OG or Domain Access), and there's no related item the user has access to. The quick work-around is to disable SQL rewriting, which allows the view to get all results and ignore the node_access rules -- of course, this will show content the user should not otherwise have access to.
Comment #102
zmove CreditAttribution: zmove commentedI think the real issue behind that is the availability of product (not product display) fields into commerce line items entity.
A possible solution to the access problem would be to make all products fields available directly on line items level, so the user that want to add the product image for example into the shopping cart just have to add the new field, without creating relations to forbidden entity type and so, without bugs.
Regards,
Alex
Comment #103
tmsimont CreditAttribution: tmsimont commentedFrom #98:
I have done this, and although anonymous users can view and modify their cart on the cart page, there is no block view in the "shopping cart contents" pane for anonymous users on the checkout page.
I'm using the Commerce 7.x-1.4 and Views 7.x-3.3
Disabling SQL rewriting solves the problem, but the exclamation point and yellow background on the security warning makes me nervous.
I know the root of this issue is #1349080: node_access filters out accessible nodes when node is left joined but surely there must be something that commerce can do to rewrite the SQL to ensure that when anonymous users are given the "access checkout" permission and the "view any product of any type privilege" that they should be able to see products in their shopping cart on the checkout pages.
This is not the case right now...
If the issue were truly related to permissions on the related product type, then the solution offered in #98 would work and I'd be satisfied this is not a commerce issue. But that doesn't work. So I'm not satisfied :p
I'll probably just go with disabling SQL rewriting, but are you guys sure that this problem is not solvable in commerce?
Comment #104
jday CreditAttribution: jday commentedI think the add to cart/checkout for anonymous users stopped working for me once I added a new Line item type, for customizable products. I've tried all of the 'fixes' that are posted in this thread and unfortunately none of them have worked for me.
Comment #105
AndyF CreditAttribution: AndyF commented@jday Forgive me if I'm barking entirely up the wrong tree, but have you configured the add-to-cart button to create the right kind of line item?
Comment #106
jday CreditAttribution: jday commented@AndyF If you mean check the box for " Include this field on Add to Cart forms for line items of this type. " then yes, I did that. If you mean something else, I'd love to hear that I just missed a setting somewhere. This is the product with the line item fields: http://offtilt.asdhost.net/custom-built-poker-table
If you visit it, you will see that you can not add it (or any other 'regular' products) to the cart when not logged in.
Comment #107
bradsmithcpa CreditAttribution: bradsmithcpa commentedLike so many others, when authenticated users added a product to the cart on one of my websites, it worked, but anonymous users could not add items to the cart. I tried everything on this forum and others to no avail. I finally ran across this post:
http://www.ubercart.org/forum/bug_reports/8693/anonymous_user_add_cart_d...
Even though the post was for Ubercart, the problem for me was the same. Somehow UID 0 for guests got deleted from the users table in my sql database. It may have happened when I upgraded to Drupal 7. Anyway, I went into the database and reinstated UID = 0. Now it works great.
The solution makes sense because line items in the cart get appended with a UID (I think) and if a UID isn't set up for anonymous users, it couldn't add the items to the cart. This also explains the maddening problem of why the product works for some and not others (or at least one possible reason).
For a possible product enhancement I wonder if during the Drupal commerce module installation if a routine couldn't verify that uid=0 exists and if not, set it up; or at the very least add a status message that says User ID 0 is not set up on the system". Its pretty important for cart modules.
I hope this post helps others.
Comment #108
BWPanda CreditAttribution: BWPanda commentedI was experiencing exactly the same problem as @jday: anonymous users couldn't add products to cart, despite implementing all the solutions mentioned above.
I solved the issue when I realised that I had the $cookie_domain variable set in settings.php (a requirement of using the TinyBrowser module) and was accessing the site at a different URL for testing. I unset the variable temporarily and it now works (even without the 'fixes' mentioned above).
I recommend adding a new 'fix' to the list: unset $cookie_domain or check that it's set correctly.
Hopefully that'll help others with the same issue.
Comment #109
fonant CreditAttribution: fonant commentedFix in #98, assigning "View any product of any type" to anonymous users (ignoring the erroneous security warning on the permissions page), works for me.
Comment #110
Yaron Tal CreditAttribution: Yaron Tal commentedFix from #6 is better if you have the domain module (or any other access module that uses sql rewriting) enabled. That way your cart will still only display items from the current domain, and not show items to which you don't have access.
Comment #111
gynekolog CreditAttribution: gynekolog commentedI mean that problem is in taxonomy field in product.
I have a product of type "Shoe" with taxonomy field "Maker". When I clear cache and load some product display with referenced product (Shoe) like user without id 1, I see all fields except field "Maker". Catalog view is empty. But when I load catalog view like admin (user with ID 1), all is OK.
Solution..?
Comment #112
freelock@gynekolog do you have any access module enabled? og_access, domain_access, tac? If this is at all related to #1349080: node_access filters out accessible nodes when node is left joined, I'd like to get more test cases.
And I'm also looking for more people to review my patch on that case, whether it's a valid approach -- once that's confirmed I'll be happy to backport to D7.
Comment #113
gynekolog CreditAttribution: gynekolog commented@freelock
I had no access module on. I downloaded and activated the module http://drupal.org/project/taxonomy_access, disable the privilege to view the term and then enable again and the problem is solved.
Comment #114
predde CreditAttribution: predde commentedThis one's got me a bit stumped. Running Commerce 7.x-1.5 and Views 7.x-3.5. I've set View permissions to "View any product of any type." I've tried disabling SQL rewriting. Flushed the cache. Checked to make sure UID 0 still exists (per #107). But I still can't get the view to display for anonymous users (authenticated users can view it without issue). Wondering if anyone else out there has an alternate solution. Thanks.
Comment #115
star-szr@predde - It sounds like you may not have assigned the "View any product of any type" permission to anonymous users at admin/people/permissions.
Comment #116
predde CreditAttribution: predde commentedBingo @Cottser. Thanks.
Comment #117
FAAREIA CreditAttribution: FAAREIA commentedThanks @Cottser (#115)
Comment #118
HyperGlide CreditAttribution: HyperGlide commentedLinking related issue #1303194: Clarify security implications of granting "View any Product product" permission.
Comment #119
albertguedes CreditAttribution: albertguedes commentedTanks dude ! I had created a view products with glossary and anonymous users culd not see. Your tip help me :D
Comment #120
jkopel CreditAttribution: jkopel commentedI just want to throw in a comment about a real use case where the "View any Product product" permission is not appropriate, and where I have had to resort to disabling query re-writing to get a cart view to show.
We have a complicated site in which certain user roles are allowed to create and buy their own products (don't ask).
But only THEY are allowed to see/purchase them.
I need to add a product relationship to the cart so it displays the product details, but I don't want to allow them to see other user's products elsewhere.
So I am stuck with the disable query re-write as my only solution since it is local to the cart and does not have the global permissions implications.
My question is... why does that relationship plugin enforce the access permission?
There are plenty of ways to enforce permissions that are deliberate and determinate, such as assigning access control in a view, or using a views relationship or filter, but only if the choice is left up to me.
This kind of behind the scenes magic makes it hard to figure out why things are happening (I would offer the 119 comments here as proof of that), and none of the options for solving it are appealing.
Comment #121
freelock@jkopel, I still think this is a core bug: #1349080: node_access filters out accessible nodes when node is left joined. It happens whenever a relationship introduces the node table a second time into any query that is tagged with node_access (which views does, unless you disable the rewrite query option).
Does the node table appear in the generated SQL? Is there a LEFT JOIN between the two instances of the node table? Does the query work as visible in Views when you try it in MySQL? If yes to all three, it's almost certainly that core bug biting you -- its net effect is to turn that LEFT JOIN into an INNER JOIN.
If you want to see this fixed, please come review my patch, and let's get this fixed in core!
Comment #122
prorokxp CreditAttribution: prorokxp commentedHi, I have very similar problem here - https://drupal.org/node/2105309
I created new order and line item types to implement two shopping carts on my site. It works great, but for anonymous users I must enable "View any orders of any type" to allow anonymous users to view the second basket. "View own orders of any type" does not work for such task.
I have no "Node reference" relation in my view. It is clean clone from default Commerce Shopping cart view.
Comment #123
jkopel CreditAttribution: jkopel commented@freelock like @prorokxp says, there are no node table joins in the query that I can find.
I don't think that is what is going on in this particular case.
Admittedly I have turned off query rerwiting and moved on, since I have to hit a deadline, but once I am done I indent to come back and spend some more time on this.
Comment #124
freelockIt doesn't need to be two instances of the node table -- it just needs to join a node table with a left join for the core bug to trigger a problem.
Here's a thoroughly unvetted patch to try -- after applying this patch, can you turn on SQL rewriting in the view and get the expected results?
If so, this is definitely the same issue. If not, it could be that my patch is incomplete -- it's checking specifically node_access applied to the node table, but there are also joins that might get written incorrectly to other entity tables. I don't yet have a good test case for that condition.
Also in my very quick backport from D8, I'm not noticing where the placeholders are generated -- this almost certainly is an incomplete patch -- what's missing are tests and improper placeholder name rewriting. If you hit that, you'll get a SQL error, so that's a pretty obvious fail ;-)
In any case, I'd love some feedback on whether this patch fixes this specific issue.
Comment #126
freelockPatch fails to apply because it is against core, not commerce. Can I get somebody to test this locally to see if it indeed addresses this issue? If so, then perhaps we can get some more people reviewing the core issue ;-)
Comment #127
AnybodyI can confirm that the problem still exists and happens in this query for my case (see the WHERE "1=0" at the end)
SELECT commerce_recurring.id AS id, commerce_recurring.status AS commerce_recurring_status, commerce_product_field_data_commerce_recurring_ref_product.product_id AS commerce_product_field_data_commerce_recurring_ref_product_p, commerce_recurring.uid AS commerce_recurring_uid, commerce_recurring.start_date AS commerce_recurring_start_date, commerce_recurring.due_date AS commerce_recurring_due_date, commerce_recurring.end_date AS commerce_recurring_end_date, 'commerce_recurring' AS field_data_field_subscription_topics_commerce_recurring_enti, 'commerce_product' AS field_data_field_recurring_cockpits_cardina_commerce_product FROM commerce_recurring commerce_recurring LEFT JOIN field_data_commerce_recurring_ref_product field_data_commerce_recurring_ref_product ON commerce_recurring.id = field_data_commerce_recurring_ref_product.entity_id AND (field_data_commerce_recurring_ref_product.entity_type = 'commerce_recurring' AND field_data_commerce_recurring_ref_product.deleted = '0') INNER JOIN commerce_product commerce_product_field_data_commerce_recurring_ref_product ON field_data_commerce_recurring_ref_product.commerce_recurring_ref_product_target_id = commerce_product_field_data_commerce_recurring_ref_product.product_id WHERE (( (commerce_recurring.uid = '8601' ) ))AND (1 = 0) ORDER BY id ASC LIMIT 50 OFFSET 0
I hope this example perhaps helps in the Discussion.
Removing the entity reference solves the problem.
Comment #128
ezheidtmann CreditAttribution: ezheidtmann commentedFYI, I just added a new issue which might be due to the same underlying bug: #2155713: commerce_entity_access_query_alter can add crazy conditions if the base table does not match the entity type
Comment #129
ahhao CreditAttribution: ahhao commented124: commerce.cart_.1276450-124.patch queued for re-testing.
Comment #131
AnybodyComment #132
lameei CreditAttribution: lameei commented#5 and #6 not working for me. cache is cleared but no products for anon and authenticated users.
Comment #133
lameei CreditAttribution: lameei commentedI got something. After putting the checkmarks in "View any [TYPE] product" and saving the page and getting the security warning i can see that there is no checkmark for "View any [TYPE] product" any more. So anon and authenticated users are not getting the needed permissions.
Is there any settings to handle this automatic security check?
Comment #134
lameei CreditAttribution: lameei commentedI've found the solution. The "paranoia" module which was included in "drupal commons" was protecting the change of permissions. This module will not get listed in admin/modules page and you need to use drsuh to disable it.
Comment #135
Mschudders CreditAttribution: Mschudders commentedconfirm that this is still the issue and no solution worked for me
Comment #136
rszrama CreditAttribution: rszrama commentedI can say definitively that the solution in most cases is to edit the View's query settings to disable SQL rewriting and use filters to control access to entities in the View's result. This has been described several times above, and having worked through the same issue on multiple sites now, it's the safe and most obvious solution.
Most Views in Commerce this applies to are going to limit their results to specific entities as a result of contextual filters passed in - a shopping cart order ID or a specific set of line items. In these cases, access control has already been performed, so I know, for example, that it's safe to disable SQL rewriting when joining from the cart View's line items to their referenced products. Even without the access control system determining if my user account technically has access to "view product 1", I know that since I added it to my cart it should be displayed to me.
The alternative, also documented above, would be to enable "view any product entity" permission for all users. That isn't a safe default recommendation, because we don't know what a particular site might be doing to display products to users dependent on the access check, but if you know it's safe for your site (i.e. because there's no way aside from product references for product entities to be displayed on your site), then it's also a fair solution.
About the only thing I can imagine us doing is determining product view access based on a user's access to view any other entity that references that product. I have no clue what that would do for performance of a site in general, especially on catalog pages, but I'm assuming it wouldn't be good.
Comment #137
freelockHi,
How about getting some help on the underlying issue, #1349080: node_access filters out accessible nodes when node is left joined? This is a fixable problem. The current patches over there need to be updated to properly generate placeholders for the database that can never collide, and there's some strange Postgres conflict happening.
If that core bug gets fixed and released, this one will resolve itself.
I do agree with Ryan that it is generally safe to disable SQL rewriting, though it's possible this could expose individual products to users who should not have access to them, if you have a complex access system... If the underlying issue gets resolved, entity access rules should enforce appropriately. If it doesn't, you need to enforce any such rules yourself in the view and disable SQL rewriting.
Comment #138
Kojo Unsui CreditAttribution: Kojo Unsui commentedAs per #134, if you have Commerce installed with Drupal Commons, in order to enable "view any product entity" permission for all users, you have to disable first the "paranoia" module which is included in Commons Distribution, and is protecting the change of permissions.
This module will not get listed in admin/modules page and you need drush to disable it :
drush pm-disable paranoia
. Very useful for me, thanks to Lameei !Comment #139
caschbre CreditAttribution: caschbre commentedI'm running into this issue as well.
I've created a custom view with a relationship to 'Commerce Line item: Referenced products'. When I do this an anonymous user sees nothing. If I disable sql rewriting then the user can at least see the line item total.
I also added the field 'Commerce Line item: Product' rendered in a specific view_mode similar to how the kickstart does it. An anonymous user does *not* see this field unless I enable the 'View any product of any type' permission. (I could use the view any [product] permissions).
So I'm not quite sure why I can't display that particular field unless the user has the extra permissions. The user can view the product display pages without issue.
Side note: the only reason I need this relationship is to get the product type so if there's another way I'm all ears, though I don't think removing that relationship solves my issue with displaying the rendered product field.
Comment #140
kip stanning CreditAttribution: kip stanning commented#4 worked for me. no idea what i'd do without this wonderful community!!!
Comment #141
dureaghin CreditAttribution: dureaghin commented#5 worked for me too. Thanks.
Comment #142
ikeigenwijs CreditAttribution: ikeigenwijs commented#5 worked for us as well
using views 7.10
We don't use commerce, but basic view with relationships and contextual filter.
Comment #143
Avi.Kumar CreditAttribution: Avi.Kumar commentedThe suggestion in #6 by 1kenthomas
Giving Permissions to Anonymous User to:
View any product of any type
Warning: Give to trusted roles only; this permission has security implications.
Seems to fix this problem problem more cleanly, without explicitly searching through all Views and changing setting there.
Comment #144
meysamm CreditAttribution: meysamm commented#4 worked for me and this solution was better than #6, because then anonymous user can search all the products.
Comment #145
duppy.ocio CreditAttribution: duppy.ocio commented#6 Did the trick. Thanks :)
Comment #146
vaibhavshah CreditAttribution: vaibhavshah commentedhow to display anonymous user history in view tab. anyone know about that. pls tell me as soon as possible. adv thanks
Comment #147
nixmd CreditAttribution: nixmd commentedI have a store which has some products which all of them should be available to anon customers. is this safe to give persmission to anon users to view all product types?
Comment #148
ethomas08 CreditAttribution: ethomas08 commentedIt is not an option to use #4 or #6 for my organization's website. :(
Comment #149
mglamanCommerce Products do not have a direct way to be viewed - they do not have a direct front facing entity display path and are referenced through fields or Views. I'd say you are more than safe to give that permission to view product types, it's just a repercussion of the Drupal 7 Entity API - in my opinion.
So for #148 yes it has been addressed - in nearly every Commerce contrib module's queue. You either grant access to the product type permission OR on specific views disable rewriting. You should only have issues with the rewrite if you're using node access and the node table is not your base table - AFAIK.
If you're afraid of anonymous users seeing products.. well then your catalog is only available to authenticated users? Issue resolves itself on its own.
This is more of a documentation bug and general Drupa7WTF.
Comment #150
rszrama CreditAttribution: rszrama commentedI'll second Matt to confirm it's completely safe to disable SQL rewriting whenever a View has some other mechanism of filtering the results. Heck, you can even add node access checking directly to a View's filter list if you want to.
The problem is... this isn't a bug. It's a support request, and there is no technical fix. The recommendations above are appropriate and safe to use. The challenge is reading people's minds to know what they're going to search for to find help when they encounter the issue, and developers are even worse mind readers than we are documenters.
Comment #151
freelockHi,
Actually, this is a bug, in Drupal core, and there is a fix, in #1349080: node_access filters out accessible nodes when node is left joined. It just has not been committed to Drupal core yet, because the fix is a bit brittle and may not work in all corner cases. It has to do with the node_access system, and any view that connects the node table or an entity table multiple times (e.g. via a relationship), when there is any access module enabled on the site, will trigger it.
Disabling SQL rewriting will bypass the issue, and should be entirely safe to do, unless you have some access rules you want to enforce (such as products in an OG group that only members of that group should be able to see) -- in which case you can usually address that by adding your own explicit filter to the view instead of relying on the core node access to filter it out for you.
If all your products are public, there's no need for this node_access check.
Cheers,
John
Comment #152
migajos CreditAttribution: migajos commented#4 worked for me also
Comment #153
arebacollins CreditAttribution: arebacollins commented#4 worked for me as well, solved a long running issue I have had for a while.
Comment #154
kenorb CreditAttribution: kenorb commentedSame here, adding:
$handler->display->display_options['query']['options']['disable_sql_rewrite'] = TRUE;
as per #4 as workaround seems to work.
Comment #155
vacho CreditAttribution: vacho commented#4 don't work for me... and I have the last version of core drupal, commerce, views, rules...
Comment #156
jonas139 CreditAttribution: jonas139 at iO commentedHad the same problem with another (non-commerce) relationship and #4 helped. Thanks!
Comment #157
nikky171091 CreditAttribution: nikky171091 commented@rennevat
#4 worked for me..
Thanks man you save my ass.
Comment #158
BeatnikDude CreditAttribution: BeatnikDude as a volunteer commentedAS per #4 and http://drupal.org/node/1276900#comment-4980066
edit your View > "Advanced" > "Query settings" : check "Disable Query Rewritting"
Comment #159
Sinan Erdem CreditAttribution: Sinan Erdem commentedAs #155, even disabling sql rewrite doesnt work work me. Fields of the nodes is not visible for anon users.
Comment #160
hassebasse CreditAttribution: hassebasse commentedThe solution for me was in #4 and http://drupal.org/node/1276900#comment-4980066
The answer is in http://drupal.org/node/1276900#comment-4980066
edit your View > "Advanced" > "Query settings" : check "Disable Query Rewritting"
All the best
Hans
Comment #161
Dadaisme CreditAttribution: Dadaisme commentedAfter hours, it's just this "edit your View > "Advanced" > "Query settings" : check "Disable Query Rewritting""
Thx!
Comment #162
wizonesolutionsWhat's the next step here? Turning off query rewriting scares me...
Comment #163
hassebasse CreditAttribution: hassebasse commentedwizonesolutions, what is the problem wit turning off query rewriting?
Hans
Comment #164
wizonesolutionsIt means that the person maintaining the View has to have a full picture of security. This is OK sometimes, but sometimes the automatic access checking that third-party modules provide is useful, e.g. not showing nodes to users who don't have permissions to see them.
In my case, it's fine, since it's just a list of pricing plans, and I want everyone to see them.
Comment #165
freelock@Wizonesolutions the underlying issue is #1349080: node_access filters out accessible nodes when node is left joined. The next step is to get that committed to core...
Comment #166
nayanalok CreditAttribution: nayanalok commented#6 worked for me..
Comment #167
pingwin4egGot the same issue, but not related to the Cart.
The attached patch fixes the access checking in query_alter() by allowing to select rows that left-join to non-existing commerce entities.
Comment #168
amjad1233#167
I tried the patch cleared the cahche. But didn't worked well.
So reverted back and used Disable Query Rewriting which worked well for me for now.
Hopefully there will be a better solution in future.
Regards,
Amjad
Comment #169
pingwin4eg@amjad1233 well, maybe you have another issue, not related to those query conditions.
Comment #172
Pascal- CreditAttribution: Pascal- commented#4 which is the same as #5 worked for me
patch in #167 did not work
permissions to view all products were already set
Comment #173
joseph.olstadnot using commerce, just views with flag module, Comment #5 worked for us, on this display only, adjusted views advanced query settings, disabled access controls.
Comment #174
joseph.olstadComment #175
joseph.olstad#174 link didn't help, went with comment #5 solution, works nicely.
Thanks
Comment #176
DamienMcKennaThe parent issue of this Commerce-D7 issue should be the core-D7 issue rather than the core-D9 issue.