Views filter group conjunctions ignored

Hm, for me, this works as expected.
I'd also think the problem most likely lies in the Search API module and its Views integration, not in the Solr-specific module. (As a test, if you don't have too many nodes, you can create a database server, move the index to it, re-index and see if that solves the problem.)

group 2 (not exposed):
type='object' OR
type='publication'

You mean you have a filter on the type, and selected those two options?

Which version of the Search API are you using?

Ah, judging from your screenshot the solution is quite simple: Search API doesn't support Views filter groups. Just use a normal filter on type and select both types as the filter values. That should work like expected.

Are there any other Views features that are not supported by Search API, are they documented somewhere?

Honestly, I don't know. I didn't even know about filter groups until now (or, had only heard them mentioned once or twice, in passing). As I see it, there are numerous extensions for Views (both built-in and in extension modules) that are still pretty hardcoded for the default backend, or other Views defaults, which the Search API (and other systems) replaces. These extensions then won't work with Search API views, without us having really the chance to know about them, or tell the user they aren't working. (The "Global: Random" sort would be another example that popped up just one or two days ago.)
Also, when I wrote the Views integration, there was close to zero documentation for Views 3, and some inline documentation was also simply wrong. Don't know if that has improved since then, but it's also a reason why some more fancy features might not be supported by the Search API Views integration.

The Search API already supports nested filters with different conjunctions (if you weren't aware of that). The problem is just that Views 3 documentation is sparse, to say the least, and I had no idea that there even were filter groups when I implemented the Views integration, let alone how they work (which I still don't know).

If you know what the filter handler has to check in the query() function, I could probably easily add this (once I have the time), or guide you on how to add this.
Basically, to add a new filter group that hasn't got an AND conjunction, you call $query->createFilter('OR'), fill it with the conditions and then pass it to $query->filter() – almost exactly what you'd do for a database query.
Changing a filter's conjunction (especially the one on the base level) is highly discouraged, on the other hand.

Great job, thanks a lot! I'm sorry I can't test/review right now, as I'm completely buried in work, but I'll get back to this issue ASAP.

OK, I finally managed to look at this.
First off, thanks again for helping with this! Your code made it pretty clear what was to do, and it also already seemed to work quite well. However, I think having this functionality bundled centrally in the Views query class is the best way to do this. We can care about creating the needed nested filters there, when they are needed, and keep changes to the filter handlers at a bare minimum.

Please see, test and review the attached patch. Sorry that there are some cosmetic changes (array_shift() => reset(); comment changes) in there, too. The main thing is I added the filter group to all calls to condition() and filter(), there just collected the information and then later added them to the query during build(), which is the way it's „supposed“ to work anyways, I guess.

@todo: prepare for even more nested levels? (Views only has 1 level of filter groups)

I don't think that's likely to ever come (and certainly only between major versions). It would be a UI nightmare and, unless I'm totally mistaken, all possible logic operations can be expressed (albeit with some redundancy) with ANDed ORs (or ORed ANDs) anyways.

That one is better, as it correctly adds conditions/filters without a group directly to the query (important, e.g., for argument handlers).

Great, committed.

Now, while this patch may fix what it does it seems that the way SearchApiViewsQuery handles filtering could use some extra work.

This worked well before:

function my_module_views_post_build(&$view) {

$search_api_query_filter = new SearchApiQueryFilter();
// build a nice filter
$view->query->filter($search_api_query_filter);
}

now I have to change it to:

function my_module_views_post_build(&$view) {

$search_api_query_filter = new SearchApiQueryFilter();
// build a nice filter
$view->query->filter($search_api_query_filter, 1);
$view->query->build($view);
}

if I want the extra filter to be passed down to the SearchAPI Query. I don't think I should have to call build() here again, should I or shouldn't I add a filter at that point?

Can grouping be used with fulltext search?

For example I have two exposed filters - one is fulltext search and the other is sku (from commerce). I defined OR group but cannot make it to work when both filters are applied.

It works ok when searching on other fields like title and body.

This issue has not seen activity in over 2,5 years. I am therefore closing this issue to clean up the issue queue. Feel free to re-open and update this issue if you feel this issue is still relevant and of importance.