When selecting filter options in search_api_views, the default option is to filter with an OR criteria. For example if you would like to create a search_api_view that allows users to filter by taxonomy terms, the default mechanism makes it so that choosing two taxonomy terms gives the combined results from both terms rather than the results that contain both taxonomy terms.
This is hard coded into the handler_filter_options.inc file located at
contrib/search_api_views/includes/handler_filter_options.inc
An attached patch provides a radio button on the view configuration so that users can choose to have the filter with an AND criteria if they prefer.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1382170-12--views_options_filter_and.patch | 5.91 KB | drunken monkey |
| #11 | 1382170-11--views_options_filter_and.patch | 4.69 KB | drunken monkey |
| #8 | search_api-1382170-8.patch | 5.16 KB | lliss |
| #5 | search_api-provide_and_vs_or-1382170-5.patch | 5.34 KB | orakili |
| #1 | search_api-provide_and_vs_or-1382170-1.patch | 2.64 KB | lliss |
Comments
Comment #1
lliss commentedPatch attached
Comment #2
tizzo commentedI can verify that the patch is working on our site though I wonder whether there's a better way to hide an exposed filter than checking the $form_state['exposed'] on the form...
Comment #3
tizzo commentedMarking reviewed
Comment #4
jon pughI don't see any affect at all from this patch... What type of filter does this affect? I am looking for OR in fulltext search fields.
I also am not sure this is the best approach... the view should respect the settings built into views for "Allow multiple selections" and "Search keys – multiple words will be split and the filter will influence relevance."
I don't think search API views respects those settings at all right now...
Comment #5
orakili commented@Jon Pugh: sorry, I think you misunderstood this case. It's about "options" type filters like for taxonomy or list fields (file contrib/search_api_views/includes/handler_filter_options.inc). Maybe the title is a bit misleading.
I'm not sure adding another field for the conjunction (AND or OR) is the way to go. Views "options" filters use different operators: is one of, is all of etc.
Attaching a patch that adds the following operators: "Is all of" and "Is none of". It also corrects a misbehavior when "Is one of" is selected but no values are.
Comment #6
lliss commentedI think orakili has the right idea. This is much more intuituve. I've tested this patch agaisnt 7.x-1.2 and it works like a charm. Any reason we can't get this into the next dev version?
Comment #7
drunken monkeyThis is a great idea and patch, thanks! Using the operator for this seems to make much sense, to me.
However, „none of“ isn't a very good label, as I understand it, as I wouldn't know the difference to „not one of“. I think „not all of“ would be better.
Also, we should maybe only provide these options if the field is actually multi-valued – otherwise they don't make much sense.
Sorry, I haven't got the time for a more thorough code review, so maybe there are small other issues, but these two should be fixed in any case, in my opinion.
Comment #8
lliss commentedI've updated the patch to apply to the latest dev branch as of today. I considered adding some helptext to make the options more clear but I decided not to do this in the end. We could do this but views doesn't in similar cases and I used the standard views oparators as a model. I altered the operators available to us from #5 because the is "not one of" selection actually didn't make much sense. Now we have options for the operators that are identical to views' base functionality when dealing with filters on lists.
I disagree about hiding these options if you can't have multiple values though. It may be that there is only a single term for now but we want to prepare for our users to add more. We also may be in a situation where the number of allowed values could change. It seems as though the view should support being set up a certain way even if the data is not structure that way yet. Again I defer to views as the model here. We add conjunctions based on the data so no need to hide it from users in the interface.
This issue has been hanging for a while so let's try to move it along with a little more haste before the code changes so much that the patch won't apply again. I think these options are sensible, and in line with what users will expect having worked with views. I've tested it under as many conditions as I could think of and everything seems to be behaving as expected.
Comment #9
lliss commentedCan't re-queue this for testing because the branch is failing testing.
Comment #10
lliss commentedAny thoughts on adding this feature in?
Comment #11
drunken monkeyThanks for the great rewrite, and sorry it took me so long to respond! Luckily, the patch still applies, however, I still had some code cleanup to add. Please test / review the attached patch to see if it still works for your use cases, then we can finally commit this.
Comment #12
drunken monkeyOh, completely forgot about that:
I didn't mean that there is only a single option, but that the field can only have on value. E.g., the node's content type uses the Options filter, but a node will never have more than one content type (at least in Drupal 7). And in such cases, providing "Is all of" doesn't make any sense, since it could never be fulfilled for more than one selected value.
So, the attached patch includes this small update, too. Sadly, it's not as easy as I thought, as it seems we don't store the field type anywhere in the Views definition. But I just added a flag to the definition, that should work well enough.
Comment #13
drunken monkeyCommitted. Thanks for your work, everyone!
Comment #14
lliss commentedJust tested the patch off of master. Works as expected. Everything is looking good. Thanks for following up on this.