Logic flaw using OR operator with hierarchy

To expand on what Chris said, the issue here is that the 2nd level links onwards in a hierarchical facet using the or operator send the parent ID too. This is effectively the same as only specifying the parent ID in the query.

I've fixed this in the attached patch. I'm not 100% sure about the approach, but from the testing I've done it's functionally correct. In our site, we have a heirarchical region/country facet, and with this patch applied we can select multiple countries without getting the results from entire regions like we did previously.

Thanks for highlighting the use case.

I would actually make the argument that the OR operator shouldn't be used to achieve the result you are looking for. How the Apache Solr Search module handles this use case is that it indexes the parent term along with the child so that hierarchy drill-downs work as expected.

For example, in your use case I am assuming that there is a City node that is only tagged with "City2". When Apache Solr Search indexes the node, it actually will actually associate both the "West of country" and "City2" terms with the node so that it can traverse the hierarchy as expected using the AND operator.

I believe the Search API module has a configuration option to use the same behavior. Marking as "maintainer needs more info" because that is the route I would take.

Thanks for posting,
Chris

Screenshot below showing setting in Search API:

Worked for us too, thanks a lot!

The patch from rupertj (almost) worked for me as well, the problem is when using the current search block the parent term is missing which is expected because it has been removed from the query however this is not the desire behaviour, I expect it will cause more problems with other modules relying on the query.

Bellow some screenshots to illustrate the problem (and give more info to cpliakas).

Additional information:

I have a vocabulary called location set as follow:
BELGIUM
- Charleroi
- Liège
UK
- London
- Leeds
- ...
FRANCE
- Paris
- Lyon
- ...

I use Search API and Facet API to filter venues using the location vocabulary, the venues are saved with both the country and the city (full hierarchy).

I tried the patch in #1. It was partly working, some issues I experienced with #1 are
- when unselecting a child term, the parent term is also unselected.
- facet api pretty paths are broken

I altered the patch so it would also work without those 2 issues. To use my patch, you should NOT patch facetapi, but patch the facetapi implementation in search api

You can find the new patch for search_api here:
https://www.drupal.org/node/2450227#comment-9708391

I have no experience with the apachesolr module, so I hope somebody else can write a solution for that implementation.

I re-rolled the patch, now it can be applied for the latest dev.
It would be great to solve it in FacetAPI, as for instance you implement a custom hierarchical facet, the taxonomy term-only solution does not help.
Indeed the parents are de-selected in this case, I will work further on the patch to avoid that.

I updated the code, introduced a 3rd state for the filtering components (disabled, in addition to active and inactive). I tested with a custom 2-level hierarchy and it worked well. Code reviews, suggestions are highly appreciated, especially on reducing the amount of code that's needed to achieve this goal.

The last patch works but floods the site with warnings

Notice: Undefined variable: disabled_original in FacetapiUrlProcessorStandard->getQueryString() (line 51 of /home/test/public_html/sites/all/modules/facetapi/plugins/facetapi/url_processor_standard.inc).
Warning: array_search() expects parameter 2 to be array, null given in FacetapiUrlProcessorStandard->getQueryString() (line 51 of /home/test/public_html/sites/all/modules/facetapi/plugins/facetapi/url_processor_standard.inc).