I installed the Apache Solr Node Access module and it returns zero results for anyone but user 1. I tried it both with the Node Access module as well as the Node Privacy by Role module. For each attempt I re-indexed to no avail. The only user who can get search results with the module enabled is user 1.

I can't think of anything specific to my site that could be hindering this. I checked out the node_access table and everything looks correct there, and the subquery function appears to be adding the correct fields.

Thanks!

CommentFileSizeAuthor
#7 na-383804-7.patch693 bytespwolanin

Comments

pwolanin’s picture

It works with both Organic Groups and Taxonomy Access Control Lite, so there it's not fundamentally broken, but there is indeed something wrong. I'm not sure if the problem is with our code or the Node Privacy by Role module module.

The Node Access module has a bug that we supplied a patch for long ago: http://drupal.org/node/323977 so that may be why that didn't work.

kevin hankens’s picture

Yeah, it's puzzling me. I tried the node access patch to no avail. Thanks again for the help. Here are some clues:

Indexing for grants:

nodeaccess_nodeaccess_author	integer	1
nodeaccess_nodeaccess_rid	integer	2

Anonymous user result from node_access_grants() inside _apachesolr_nodeaccess_build_subquery($account) during the search:

array ( 'all' => array ( 0 => 0, ), 'nodeaccess_rid' => array ( 0 => 1, ), 'nodeaccess_uid' => array ( 0 => 0, ), 'nodeaccess_author' => array ( 0 => 0, ), )

Anon user calls to $node_access_query->add_field() inside _apachesolr_nodeaccess_build_subquery($account) during the search:

$node_access_query->add_field('nodeaccess_all', 0);
$node_access_query->add_field('nodeaccess_nodeaccess_rid', 1);
$node_access_query->add_field('nodeaccess_nodeaccess_uid', 0);
$node_access_query->add_field('nodeaccess_nodeaccess_author', 0);

Otherwise, all grants appear to work as you would expect for viewing nodes.

pwolanin’s picture

Well the grants that are being indexed seem to indicate that content should only be visible to UID 1, or role 2 (authenticated user).

kevin hankens’s picture

So, it sounds like the issue is on the indexing phase and not the subquery phase. Here's a brief snippit from my node_access table showing a three nodes, one that should be public and two that should be private:

mysql> select * from node_access;
+-----+-----+-------------------+------------+--------------+--------------+
| nid | gid | realm             | grant_view | grant_update | grant_delete |
+-----+-----+-------------------+------------+--------------+--------------+
...
| 121 |   1 | nodeaccess_rid    |          1 |            0 |            0 | 
| 121 |   2 | nodeaccess_rid    |          1 |            0 |            0 | 
| 121 |   1 | nodeaccess_author |          1 |            1 |            1 | 
| 122 |   1 | nodeaccess_author |          1 |            1 |            1 | 
| 123 |   1 | nodeaccess_author |          1 |            1 |            1 | 
...

Here's what's being added to the document in apachesolr_nodeaccess_apachesolr_update_index(&$document, $node) (excuse the format, it's just how I was logging it)

indexing: nid:123 nodeaccess_nodeaccess_author => 1
indexing: nid:122 nodeaccess_nodeaccess_author => 1
indexing: nid:121 nodeaccess_nodeaccess_rid => 2
indexing: nid:121 nodeaccess_nodeaccess_rid => 1
indexing: nid:121 nodeaccess_nodeaccess_author => 1

Any clues there??

-- EDIT --

Also, no results for authenticated users

kevin hankens’s picture

Sorry for the deluge of snippits!! :)

Here's the document array for nid: 121 (should be public above) as it passes apachesolr_nodeaccess_apachesolr_update_index(&$document, $node):

Apache_Solr_Document::__set_state(array( '_documentBoost' => false, '_fields' => array ( 'id' => 'b2a2dc1c9c1521e92773fbec9509b4db/node/121', 'site' => 'http://kevinhankens.com/', 'hash' => 'b2a2dc1c9c1521e92773fbec9509b4db', 'nid' => '121', 'uid' => '1', 'title' => 'I love lamp', 'status' => '1', 'sticky' => '0', 'promote' => '1', 'moderate' => '0', 'tnid' => '0', 'translate' => '0', 'language' => '', 'body' => 'Finally finished the lamp today. I had to disguise a few happy accidents, but all in all I\'m pretty happy with it. I tried a new method for the patina, which included adding a few pinches of salt and doing a very gentle wipe with a cotton cloth. The patina was crazy quick and has that nice cobalt luster (in most places). The lamp cap took fooor eeeevvveer to patina, but looks just as good as the solder with a near perfect color match. ()', 'type' => 'project', 'type_name' => 'Project', 'created' => '2009-02-22T23:56:47Z', 'changed' => '2009-02-23T00:13:36Z', 'last_comment_or_change' => '2009-02-23T00:13:36Z', 'comment_count' => '0', 'name' => 'Kevin Hankens', 'url' => 'http://kevinhankens.com/content/i-love-lamp', 'path' => 'node/121', 'path_alias' => 'content/i-love-lamp', 'tags_inline' => ' happy accidents', 'tags_a' => ' ()', 'nodeaccess_nodeaccess_author' => array ( 0 => '1', ), 'nodeaccess_nodeaccess_rid' => array ( 0 => '1', 1 => '2', ), ), '_fieldBoosts' => array ( 'id' => false, 'site' => false, 'hash' => false, 'nid' => false, 'uid' => false, 'title' => false, 'status' => false, 'sticky' => false, 'promote' => false, 'moderate' => false, 'tnid' => false, 'translate' => false, 'language' => false, 'body' => false, 'type' => false, 'type_name' => false, 'created' => false, 'changed' => false, 'last_comment_or_change' => false, 'comment_count' => false, 'name' => false, 'url' => false, 'path' => false, 'path_alias' => false, 'tags_inline' => false, 'tags_a' => false, 'nodeaccess_nodeaccess_author' => false, 'nodeaccess_nodeaccess_rid' => false, ), ))

Particularly:

'nodeaccess_nodeaccess_author' => array ( 0 => '1', ), 'nodeaccess_nodeaccess_rid' => array ( 0 => '1', 1 => '2', ),

I certainly appreciate the help!! :)

pwolanin’s picture

We only care about grant view for search purposes.

From the above it seems as though the right data is getting indexed - in which case it may be a problem in terms of constructing the query.

pwolanin’s picture

Status: Active » Needs review
StatusFileSize
new693 bytes

brilliant insight by Jacob - a fast computer may actually complete multiple operations in one microsec.

no reason to be time based anyhow - a simple static counter is more robust.

JacobSingh’s picture

Status: Needs review » Fixed

committed.

JacobSingh’s picture

Status: Fixed » Needs review

err... not really

pwolanin’s picture

Status: Needs review » Fixed

yes - I committed.

Status: Fixed » Closed (fixed)

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