Solr + organic groups (og)

We have gone ahead and developed a new module to take care of apache_solr integration with organic groups. It allows apache solr to either search within a group the user is subscribed to, or to search within all non-group content as well as any groups the current user is subscribed to. The provided block alternates between the two functionalities automatically, depending on the current group context it finds itself in.

The apachesolr_og module is meant to reside in the apachesolr/contrib/ folder, and be included in this project if that is acceptable. In order to implement the desired functionality, a minor patch was required on apachesolr_search.module. This patch involves moving the actual search functionality to a separate function in the module, and then checking for permissions in the module. This allowed us to disable the overall site apachesolr search and enable ours, which was required to ensure security against users being able to search content in groups of which they are not a member.

The module works by indexing group_id and group_name (which is currently unused) along with the other data crawled, using the hook_update_index() interface. This requires the included schema.xml file to be used in lieu of that provided by the original apachesolr module. Subsequently, the apachesolr_og implements its own hooks for the search module, checking its own permissions, and filtering the query to make sure it limits results to groups the user is subscribed to--either a single group or all group and non-group content depending on the request.

For the organic groups-based security to be effective, the original apachesolr search permissions should be set to none, which is done by default in the permission settings included in our patch. This module has not been tested with the apachesolr_image contrib module, although it is most likely that it would continue to function as it does now, including the fact that it wouldn't have permissions independent from apachesolr.

Although this module is does not provide full access control by any means, it works sufficiently in our case, where content is partitioned by organic group. Also, it does not provide for viewing content in groups to which the user is not subscribed, even if the group is public and the content could be viewed. However, the worst case scenario is that viewable content will be ignored--no group content the user cannot view will be returned, much unlike the current apachesolr search, providing the security we needed in our site's implementation.

Awesome! I can hardly wait to review.

I'm happy to make changes to OG as needed to better support public posts in groups or whatever.

There's a bug in apachesolr_og.module; there is actually no Group information being added during indexing. This is due to a misnamed function:
function apachesolr_og_update_index(&$document=null, $node=null) {
should really be:
function apachesolr_og_apachesolr_update_index(&$document=null, $node=null) {

hello! Sorry about that janusman--somehow some older code must have been stuck into that tar by accident. However, we have that fixed, and I've also added a more permissive security system for apachesolr_og that allows for parentheses and quotes. Also, I'd highly suggest looking at my other post at http://drupal.org/node/258882 on the performance issues caused by a bug in the looping done in apachesolr.module's update index function, as that is a significantly more critical change than this.

Hi,
These days I just started using Apchce-solr search inregration on my website. It's great to find that there is lot more we can do with apache solr.
Will try this "apachesolr_og" module as well. :)

Thanks! I just installed, but found another "bug" (?) that is also in the earlier version: clicking on a facet loses the group context from which the search was launched.

Example: I am in group (with nid=727), and from there searching for "book" produces this URL:

http://bibdig.mty.itesm.mx/search/apachesolr_og/book?gids[]=727

... which is fine, but clicking on a facet--say, content type=biblio, produces this URL which losese the gids[] context:

http://bibdig.mty.itesm.mx/search/apachesolr_og/book+type%3Abiblio

Perhaps the group context should go in an argument, say

http://bibdig.mty.itesm.mx/search/apachesolr_og/727/book

A fix for my previous comment is attached: this is to be applied to apachesolr.module.

I just attached a $query argument to calls to l() which produce facets, which contains the gids[] argument for the current page.

You can watch this in action here:

http://bibdig.mty.itesm.mx/search/apachesolr_og/book?gids[]=727

this is a search from within group with id=727 for "books". Facets now include the gids[] argument.

Hey,

Thanks for the find and fix. We hadn't really been using the included faceting implementation, so it must have been overlooked. I'm glad you already found this module useful on one of your sites!

David

Is this issue still active?

Yes, still active. I want to know if it is actually needed, or if a generic node access solution will suffice.

This module (apachesolr_nodeaccess) and modification to schema.xml works for me upon initial testing of organic groups!!! Thanks to JacobSingh and pwolanin.

http://drupal.org/node/230383#comment-1091086

So are we done here?

I think so.

Please see http://drupal.org/node/230383#comment-1288636 and any later comments on that thread for the Drupal 5 version of the apachesolr_nodeaccess fix (which solves the og access permissions issue for Solr) and the commit status of what version (if any) it's committed to.