Grouped exposed taxonomy term filters do not work

I can confirm the patch in #1 fixes the issue where the grouped value contains an array (multiple items).

Attached is the rerolled patch.

Retrying that patch.

Here is an edge case:

1) Start with the filter type to expose: single filter
2) Check: Reduce duplicates
3) Apply the filter settings and save view
4) Edit the view; change the filter type to expose from single to group
5) Save

Now, when you export the view you'll notice that 'Reduce duplicates' is still set to TRUE for this filter. That makes it so the above patch never gets triggered. Also, the SQL is invalid (there's an empty AND in WHERE, and the contents of the AND are applied to the LEFT JOIN statement.

e.g.

LEFT JOIN {taxonomy_index} node_field_data_field_health_plan__taxonomy_index ON node_field_data_field_health_plan.nid = node_field_data_field_health_plan__taxonomy_index.nid AND node_field_data_field_health_plan__taxonomy_index.tid = '827', '826', '830', '868'
WHERE (( (node.status = '1') AND (node.type IN  ('physician')) AND (field_data_field_medical_group.field_medical_group_target_id IN  ('171', '180')) AND( (taxonomy_index_value_0.tid = '527') OR (taxonomy_index_value_1.tid = '12') OR (taxonomy_index_value_2.tid = '575') )AND ()) ))

I got this error, but I also got
Notice: Undefined index: field_animals_tid in views_handler_filter_term_node_tid->exposed_validate() (line 262 of ...\public_html\sites\all\modules\views\modules\taxonomy\views_handler_filter_term_node_tid.inc).

Given that #7 already indicated that the available patch is patch work and not solving the underlying problem, I started working on solving it there were it originates. #7 indicates that settings from the single filte and grouped filter settings are intermixed or not correctly used. The notices indicate that the wrong data is inspected.

Anyway, I started working on the notices, and once I had solved that, I could no longer reproduce the error (no results due to error in query) and testing showed that the filter also really worked. The problem mentioned in #7 was also no longer reproducable. So, I am posting the patch for the notices here as patch for the whole problem, even if I cannot fully explain why the patch should resolve the error.

Can someone else test this patch and see if it also works for you?

I just applied #8 and that fixed for grouped filters showing blank at least if you don't have it set to "allow multiple selections". Once multiple is selected it still works if you select one option at a time, but if you select more than one option it goes blank.

Just did some more testing and it does work with multiple selections if you have the grouped filter in another filter group with an Or operator in the group and And operator linking the groups.

Tried the patch in #8, but didn't work for me.

If I have 3 groups on a taxonomy field, the first selecting 3 terms and the last two selecting one term each, the last two options work, but the first option with three terms selected gives no results.

Tested with dropdown only.

Just tried using "is none of" instead of "is one of" with reversed selection logic and it seems to be working ok. I'm running unpatched version.
It may be quick fix for someone.

I had the same issue, but I just had to enable "allow multiple selections", save the view, disable that option and the query is now correctly using "IN" operator. Seems like when the filter was created something went wrong.

I'm confirming #14 works. Just set to multiple selections, save view, and then un-check multiple selections

Spent a couple of hours with this problem... Thank you Konrad, that solution gives the desired result. When you do that this line will enter in the view
$handler->display->display_options['filters']['field_FIELDNAME_tid']['expose']['multiple'] = TRUE;

Which problably explains what I experienced in #7, so the workaround seems to work indeed and my "patch" can be disregarded.

Is the issue in #7 still valid or is it resolved by the tip in #15? Would be nice to get this patch into Views! I just added the patch from #4 to a project where we had an exposed filter for a select field, and it worked nicely.

The issue is thus not only with taxonomy term filters.

The above comment #14 is a workarounds, not necessarily a fix.
Someone shouldn't have to look for the work-around when things don't work. An update from broken to fixed needs be included in the patch.

Ran into the same issue. #14 was the workaround I found. Seems to be when exposed group filters contain an option that only has 1 item selected along with other options that have multiple selected inside. Obviously the option with a single item works just fine, but the others don't. It looks like there is some sort of persistence from the default setting that doesn't get set correctly when switching to a grouped filter.

#10 was the workaround that solved this for me, without needing to apply any of the patches above.
- Create a new filter group connected to the main group with an AND operator
- Move your grouped filter into the filter group you just created
- Set the operator on the new filter group to OR

Agree with #19 though that it should be fixed so that a workaround isn't neccessary

This helped me resolve my issue, this was only happening when i had the views attachments.
Otherwise the group filter works as is.

This helped me resolve my issue, this was only happening when i had the views attachments.
Otherwise the group filter works as is.

Patches used to resolve my issue:
https://www.drupal.org/files/issues/views-grouped_filters-2224601-4_0.patch
https://www.drupal.org/files/issues/views-fix-exposed-filter-illegal-cho...

Possible duplicate with #1151164: Cardinality violation.
Not sure which of them should be closed.

Some research + solution.

Background / what is happening

views_handler_filter has an option $this->options['is_grouped'], which is controlled by radio options in the UI.

views_handler_filter has another option $this->options['expose']['multiple'], which can be controlled in the UI, but only if the ['is_grouped'] is disabled.
When ['is_grouped'] is enabled, the checkbox is no longer shown in the views ui, but whichever value was stored in ['expose']['multiple'] previously is still there.

There is another option ['group_info']['multiple'] for the 'is_grouped' case which looks the same in the UI but is actually independent of the ['expose']['multiple'].

Then in views_handler_filter::accept_exposed_input(), the filter value is array-fied depending on the setting of ['expose']['multiple'], even if 'is_grouped' is enabled.

With 'is_grouped' enabled, the original value is already an array.
Then if ['expose']['multiple'] s false, the value is replaced with array($value), which gives us a nested array of values like this: array(array(55, 66)), with one element at the top level.

In views_many_to_one_helper::add_filter(), there is an array_pop() that removes the top nesting level but still leaves us with an array.

Interestingly, the other condition in views_handler_filter::accept_exposed_input() is empty($this->always_multiple), which is weird, because:
- Some filter handlers have $this->always_multiple === TRUE, and $this->value is an array.
- Some filter handlers have $this->always_multiple === TRUE, but $this->value is a string.
- For those filter handlers where $this->always_multiple === TRUE, I suppose $this->value can be either string or array.

So apparently, the $this->always_multiple === TRUE does not specify the cardinality of $this->value, but only whether this cardinality can be modified through views ui.

Steps to reproduce

Create a view with taxonomy term reference field as exposed filter.

While the filter is in "Single filter" mode, disable the "Allow multiple selections" checkbox on the right.
Click "Apply", then reopen the exposed filter configuration box.
Switch to "Grouped filters" mode. Configure some groups.
Apply.

Now in the views preview you can select one of the grouped options and get the error.

(Interestingly in some cases I see the error shown in the output, in other cases I just get empty result set. Not sure why this is.)

Debug suggestions

To debug what is going on, you can:

Modify views_handler_filter::accept_exposed_input(), then put a break point or dpm():

diff --git handlers/views_handler_filter.inc handlers/views_handler_filter.inc
index 7220722e0..7d6d20414 100644
--- handlers/views_handler_filter.inc
+++ handlers/views_handler_filter.inc
@@ -1339,6 +1339,9 @@ public function accept_exposed_input($input) {
       if (isset($value)) {
         $this->value = $value;
         if (empty($this->always_multiple) && empty($this->options['expose']['multiple'])) {
+          if (is_array($value)) {
+            $x = 5;  # break point or debug statement here!
+          }
           $this->value = array($value);
         }
       }

Modify views_many_to_one_helper::add_filter(), then put a break point or dpm():

diff --git includes/handlers.inc includes/handlers.inc
index b22017075..de55cc171 100644
--- includes/handlers.inc
+++ includes/handlers.inc
@@ -1094,6 +1094,9 @@ public function add_filter() {
       }
       else {
         $value = is_array($value) ? array_pop($value) : $value;
+        if (is_array($value)) {
+          $x = 5;  # break point or debug statement here!
+        }
         $operator = '=';
       }
       $add_condition = FALSE;

Workaround 1

As a workaround, you can:
- Edit the filter
- Remember the grouped filters configuration!
- Switch to "Single filter" mode.
- Enable the "Allow multiple selections" checkbox on the right.
- Apply.
- Edit the filter
- Switch to "Grouped filters"
- Recreate the filter option groups.

Workaround 2

Alternatively, you can:
- Edit the filter, while already in "Grouped filters" mode.
- Enable the "Allow multiple selections" checkbox on the left. This is the setting for grouped mode, not the other one!
- Apply.
- Edit the filter.
- Disable the "Allow multiple selections" checkbox on the left.
- Apply.

Why?
There is a line in views_handler_filter::init(), which sets $this->options['expose']['multiple'] = TRUE when the ['group_info']['multiple'] option is enabled for grouped mode. But there is no line that changes it back when you disable the ['group_info']['multiple'] checkbox again. So changing this setting back and forth implicitly and permanently changes another, unrelated setting.

This interdependency was introduced in 274394fe3f714e043f5c4375a7eb8cd2348a21f9 / #731662: Hybrid Exposed Filters.

Solution

We need to
- prevent that a nested array is stored in $this->value
- ignore $this->options['expose']['multiple'], if we are in group mode.

If we do this, we no longer need to fix the symptoms in views_many_to_one_helper::add_filter() as in some of the other patches.

I am thinking about this, but it seems complicated to cover all the cases correctly.

Even after all the above research, I still do not understand the correct interdependency of the different settings.
I have to pass.
Perhaps the "fixing the symptoms" approach in views_many_to_one_helper is not the worst idea.

Re-roll of #6 for 3.21

Re-roll of #6 for 3.21, #27 is failing.

Some tests were committed in #3040391: 3.21 Regression, malformed SQL: 'Is none of' within grouped exposed filter that should be extended for this. Thanks.

The patch in this issue is very similar to the patch in #2036473: Grouped exposed filters produces wrong where clause. So I guess we just need one of the patches. It was a little bit difficult to decide on one of the patches, but in the end, I added the tests in the other issue, since that one is older. I hope you don't mind. I did however add another test based on the steps to reproduce in comment #25, just to make sure that the patch really fixes both issues. I just uploaded the new patch with both tests over there. It would be great, if you could check, whether it works for you and help to review it. Then we could close this one as a duplicate. Thank you.

Marking this as a duplicate of #2036473: Grouped exposed filters produces wrong where clause because they're the same issue and the other one has tests already. Thanks everyone for working on this, I'll be sure to include you in the commit message.

Thank you FeyP and DamienMcKenna for both getting this issue fixed properly and for taking the extra time to take care of my feelings by transferring issue credits and all! I don't remember what project I was working on, but I am glad that there is more balance in the universe now :-)