Closed (fixed)
Project:
Ubercart
Version:
7.x-3.x-dev
Component:
Documentation
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
15 Jun 2011 at 11:01 UTC
Updated:
22 Aug 2011 at 15:11 UTC
Hi - this is a report that I feel important to file, although I realize this is not an Ubercart problem.
Essentially there is a 'conflict' or 'incompatibility' - neither words are very appropriate but that's the only ones I can come up with now - between the Catalog Taxonomy terms view, uc_catalog and the ACL module (in my case required by Forum Access, to provide private forums to our site). As soon as the ACL module is present Anonymous users lose the uc_catalog view, making it impossible for them to browse the catalog.
No amount of tweaking of the uc_catalog View (permissions or roles) could resolve the matter for me, so I'm not sure there is anything the ubercart team could solve in the next version, but well I'll leave to someone more competent to assess whether that is possible in any way.
The only way for me to resolve this matter (short of killing our private forums... or enable 'Bypass content access control' for Anonymous users in Drupal permissions tab, err not really a viable option for obvious reasons) was to install a further module to control access to taxonomy, for example http://drupal.org/project/tac_lite
The D7 port is in its infancy and throws a bucketload of notices and warning into the watchdog logs, but at least it seems to work with no operational issue for me. YMMV.
Comments
Comment #1
longwaveSounds very similar to #1136732: Anonymous User can no longer see Catalog when Organic Groups Installed, but still not sure what Ubercart itself should be doing about this, if anything - perhaps this is a Views issue, or even a Drupal core issue regarding access control.
Comment #2
RogueM commentedI agree this does not point to a UB problem requiring a fix.
And yes, the thought that it could be a problem with Views crossed my mind, though I think the bottom line is that Taxonomy terms are denied access to, which I would suspect, as a complete non-coder, is nothing in their realm, they just allow users to include criteria or otherwise relations to taxonomy terms, without overriding permissions to these components included in the view?
The problem, to me, is that ACL should not behave in such a way as modifying access out of the box. I tried poking with the database last night in the hope to restore access to particular taxonomy terms for user Id 0 (anonymous), and while I'm really not sure of what I'm doing my conclusion was that ACL has some special handling of Anonymous users that I see no reason to have.
Take this with a pinch of salt, as appropriate, but I sure wish that the ACL page had mentioned TAC, that would have saved me a few hours of poking around.
Comment #3
shadowmihai commentedRe - Views, I messed with views settings like crazy (that's the first thing I suspected) and could not get any different behavior. I seldom get into code unless it is more than crystal clear as the last real programming I did was over 20 years ago... So if there is something there I would be sure to miss it or mess it up...
Comment #4
longwaveYes, but I'm wondering whether this is an actual bug in Views, where the code is doing/not doing something that affects anonymous users only when an access control module is in use. All Ubercart's /catalog page does is load and render the two views that are associated with it as long as the user has "view catalog" permission.
Comment #5
salvisI'm the maintainer of ACL (and Forum Access) and I'm intrigued by its implication in this thread.
ACL is an API module that doesn't do anything by itself. Specifically, ACL is completely ignorant about taxonomy. However, if you enable it, core recognizes it as a node access module, and core changes its behavior. This may also have an effect on Views.
If ACL triggers this issue, then I'd say that any node access module will trigger it. I have no idea why tac_lite would/could be able to help though. Maybe the tac_lite maintainer can shed some light on this.
RogueM told me that the catalog items were taxonomy terms. Can anon see these on their term pages? Should he?
Comment #6
RogueM commentedjust a quick note to say the problem still occur with Views 7.x-3.0-rc1 released a couple of days ago. I guess that's not surprising since it's probably just a validated build of the dev build I was running earlier.
As you know, salvis, I had an issue with Advanced Forum / Forum Access this weekend that at some point I thought could be related, but ended up being seemingly unrelated. In the context of my report on FA you did mention this however:
Can you mark your query for 'term_access'? If Views called addTag('term_access') on the query for the forum list, then you'd be all set.
I'm not sure I understand fully but would this be relevant here?
longwave, I'm not sure which View regulate the second level of the catalog (the root is uc_catalog_term I believe but that's never caused me any problem). I checked uc_catalog and that looks about right in term of fields and format, but if I follow the page path /_catalog I get a blank page, with just the word catalog displayed, regardless of the user logged in (role). Could this be the problem?
Comment #7
RogueM commentedhum, uc_catalog does not seem to be relevant, if I disable it, it makes no difference. If I add a Global text 'Our shopping cart is down for maintenance, please try again later.' under No Result behaviour in uc_catalog_term this text appears where my blank page was before, so that's the View that is used there. I will have a look at what I can add to make the catalog viewable by anon.
Comment #8
RogueM commentednow I'm really confused, I've just checked with a logged in user and the global text appears there too, so that means that's indeed uc_catalog which is called as I originally thought. Well, I think, but now I'm tinkering with that view instead...
Comment #9
RogueM commentedOK, I have resolved the problem, very simply (it's only easy when you know the answer): I have swapped the contextual filter from type Content: Has taxonomy term ID (with depth) to Content: Has taxonomy term ID. Since the depth on the original filter was set to 0 I think that the loss of functionality is nul?
well, I'm quite happy with that solution, pending someone advising me not to. TAC (lite) does create an extra layer of madness and I definitely prefer this solution, however unapplicable it may be to others with more involved catalog requirements!
Anyway, please review my findings and see if there is a better solution to put into the UB code. Well unless you find it's a bug in Views which it could well be, but I wouldn't know :-)
My deepest apology to salvis for pointing the finger at ACL.
Comment #10
salvisNo problem, glad you found a solution (which I don't understand, but never mind).
Comment #11
shadowmihai commentedAs far as I can tell, ANY node access module does trigger it. Anything that rewrites or messes with access like Organic Groups, TAC or others I have tried has the same effect.
Comment #12
salvisThank you, shadowmihai.
Let's tentatively broaden the scope of the issue.
Comment #13
longwaveThe catalog page is generated entirely by Views, which is why I still don't think this is Ubercart's fault directly. However, the clue about the "taxonomy term with depth" contextual filter lead me to #1201908: Taxonomy filter with depth generating incorrect results because of core subquery bug, which in turn leads to a possible core issue: #1112854: Subqueries use wrong arguments
But, perhaps we can just switch the filter as RogueM suggests to fix this in Ubercart at least.
Comment #14
shadowmihai commentedAre you aware of the issue here:
http://drupal.org/node/1057400
which seems to be associated with similar if not identical matters, and which is supposed to have been fixed as of D7.4 (I won't have a chance to test myself for a while).
Comment #15
longwaveDoes this still occur in Drupal 7.4?
Comment #16
RogueM commentedI will have to try specifically when time allows. I'm planning to upgrade core to 7.7 in a couple of weeks time too, so will try with both versions.
Comment #17
RogueM commentedt's definitely still an issue here with core 7.4. I'm using an ubercart dev from early July. I want to upgrade core first to 7.7, then I'll get up to date with UB and the rest of my modules. Will report the result after each step.
Comment #18
RogueM commentedand still occurs with core 7.7, with latest stable uc. and latest dev for views.
I note that in another thread, that I deem, right or wrong, related someone with it seems some knowledge of Views stated:
"Views 3 has the option to disable SQL rewriting on a view". Here is the post, if that helps:
http://drupal.org/node/1189144
To me though, without exact knowledge of exactly how the uc_catalog view shipping differs from my mod on any other site but mine, it would seem to make sense to implement it. Perhaps my shop is not complex enough to fully appreciate the impact this would have elsewhere though.
Comment #19
RogueM commentederr, hold on. It seems the latest views-dev may have fixed the matter. I'm going to try to revert back to the previous one and ensure I get the problem back, then its resolution with the Views update, as a sanity check.
Comment #20
RogueM commentedyes, somewhere between the 20th June and now, the Views team made a change that completely fixes the issue, as far as I can see. In other words, the Views-dev dated 8 Aug works in combination with core 7.7 and ubercart 7.x-3.0-beta4. Result - I am changing the status to fixed then.