Closed (fixed)
Project:
Apache Solr Search
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
14 Aug 2009 at 22:00 UTC
Updated:
12 Sep 2011 at 15:01 UTC
Jump to comment: Most recent file
Comments
Comment #1
Scott Reynolds commenteddoh! apparently i had a conflict in the schema file :-D. so we will try this again
Comment #2
robertdouglass commentedI guess we can start out making exceptions this way. Later, if the landscape gets too crowded and too many special cases are being made we need to abstract, but that seems like too much work for this one case. The plugin sounds very interesting. Look forward to testing it.
Comment #3
Scott Reynolds commentedI think if i gets to that point, we start looking to build a tags/metadata system like what we see in D7 dynamic select queries.
Comment #4
robertdouglass commentedCommitted to 6.2. Alone for adding the $caller param it is worth it.
Peter, do you want to apply to 6.1?
Comment #5
pwolanin commentedThis should really be a setting - so it should be a variable_get() of an array of module names to omit node access
Comment #6
pwolanin commentedPer discussion today - seems wrong that the Views integration module needs this at all - why would it not rely on Solr to do the filtering?
Comment #7
Scott Reynolds commentedSimple, I want it configurable. So lets say the following.
I want only those nodes that are node_access 0. Meaning all public posts. You don't want the url to solr to have all the node access stuff like (node_access:dalfjd:14 || node_addess:djakldaklfd:60) and then add in node_access:all:0.
Wasted stuff in the url.
What if I only want things that match a node access record for a subdomain? What if Im not on that subdomain currently?
What if I want to say give me all the nodes in this group that are public. EVEN if I am a member of the private group.
It is a pet peeve of mine, that all SQL queries for nodes have ALL the node access stuff applied. What if thats not what I want? I want to be able to say exactly which node access rules I want applied through an interface, per query. It is a user experience fail. But Im digressing.
Comment #8
pwolanin commented@Scott - sounds more like a developer experience, rather than user experience issue.
Comment #9
Scott Reynolds commented? really?
A user creates a private post and then searches for that post. And then they see it there. And they say
"Hey I thought this was private"
Comment #10
pwolanin commented@Scott - how is that different than the same user seeing their post in a list of content.
I strongly disagree with breaking out of the standard nodeaccess framework - this is basically jsut asking for regular access bypass problems.
Comment #11
Scott Reynolds commentedSo because Core has a major usability fail we should just keep it standard? How many users do you know that understand this?
Regardless, I will change the handler. Just disappointing...
Comment #12
jpmckinney commentedHaving nodeaccess integration that allows modules to bypass it is asking for trouble. Re-open with better proposal if still needed.
Comment #13
franzOh wait.
There was a bypass committed regarding this issue: http://drupalcode.org/project/apachesolr.git/commit/eb8fc046c2191dd28990...
Look. It is NOT expected that restricted nodes show up in search results (using apachesolr_views) unless you manually restrict them. During the time it takes for someone to notice this, there will be private content exposed. Please make a regression of that commit ASAP.
Comment #14
pwolanin commentedreverted that commit.