Error when configuring exposed group filter: "The value is required if title for this item is defined."

Same here. If you find solution please update the issue.

@gthing

Please try this patch.

Had the same problem, the patch in #3 fixed the error. Thanks!

I can confirm this bug for the "is empty" and "is not empty" operators when making a grouped filter. Choosing another operator, then entering some value, then returning to the "is empty" or "is not empty" operator makes the error go away.

@marcelæ, consider trying the patch :)

This patch does not fix the issue described in #5. The workaround for empty/not empty grouped filters is to enter a (bogus) value in the value field and submit the form.

Can those that found the patch in #3 fixed their issue, please give more details about their view settings? (Exporting the view is ideal).

Here is the issue for 8.x #1785318: Grouped filter doesn't allow you to use fields without a value Is really easy to fix, maybe somebody can provide a similar patch here.

Thanks, dagmar.

I also added some code to correct the #dependency settings (prior code assumed #dependency only for value widgets with multiple fields such as in-between). So now the value textfield disappears in the UI when empty or not empty are selected.

Thanks, patch #3 worked nicely. I was simply trying to have a NULL/NOT NULL filter for a field.

This is reworked version of the #3 patch using approach used in the #9 patch.

Difference from #3 patch:
* check amount of operator's values

Difference from #9 patch:
* making code easier to read
* not using suggested changes in dependencies. mikeker, please create a follow-up.

Can't we reuse the tests from #1785318: Grouped filter doesn't allow you to use fields without a value here?

If you don't know tests, you should learn it :)

#11 Works for me.

when will #11 be committed?

thanks

My work around was to select an operator that uses a value like "greater than". Gave it value of 1, apply it, then edit it again and change it to "not empty" and it didn't throw the error and let me save it.

I take it back. It doesn't work properly even though it let me save it. My error log shows : Illegal choice in field_user_image_fid element. I will try the patch.

The patch in #11 worked for me too.

#11 works for me too so I guess this should really be commited.

@OnkelTerm

I try to figure out why dropping #dependency from the patch is actually out of scope of this issue. This issue is about the wrong assumption that you always have a value.

Re-rolled #11 against 7.x-3.8.

Commit please??

I have stumbled onto this also. Manually applied #20 to 3.8 and it works.
Please commit.

Some strange bug: when changing filter identifier - the filter is not displayed. Can anybody confirm?

Is common to have problems with the exposed filter disappearing when selecting "is empty" or "not empty", but I don't remember the fix sorry.
Anyway, I don't think it is related to this.

Please can we have a release? It's almost 1 year since it's reviewed and 2 years & half since bug issue was created.

a commit would be nice.
Patch still valid for 3.11

Confirming patch in #20 worked for me on 7.x-.3.11

Patch #20 works for me as well. Echoing what's already been said here but it would be great to see this committed.

No one has addressed the question by @dawehner in #19:

I try to figure out why dropping #dependency from the patch is actually out of scope of this issue. This issue is about the wrong assumption that you always have a value.

I get the following error after manually applying #20:

Call to undefined method SearchApiViewsHandlerFilter::operators() in /var/aegir/platforms/panopoly-7.x-1.26/profiles/panopoly/modules/contrib/views/handlers/views_handler_filter.inc on line 620

Line 620 references the following line that was added by the patch:

$operators = $this->operators();

The error appears when I am trying to save an exposed group filter which filters an indexed field. Is it possible that it doesn't yet work on Search API Indexed Views?

any work on this?

I got stung by this just last week.

I got stung by this this week as well. Patch #20 does address the issue, but I don't think it's right. In truth, the only operators that should not have a value associated with it are the EMPTY and NOT EMPTY. I'm proposing patch #33 to address that. Hopefully it will have the added bonus alleviating the Search API issues NWOM was having in comment #29.

Changing status to "Needs Review."

My apologies… I rolled that last patch from the wrong folder. Patch #36 should apply without issue.

Well, this is embarrassing… #37 should really apply this time. Pinky swear!

Edit: I just tested building my profile with this patch and it applied. Apologies for creating any confusion.

Tested and works as advertised.

#37 looks good to me

RTBC++ this still works. Thanks @deetergp

#37 works brilliantly. Thanks! Big UX problem solved :)

#37 any verify

commit please!

5 yeses for RTBC! :)

I also came across this bug. #37 fixes it - thanks!

.patch #37 applied cleanly on latest stable 7.x-3.18 - thanks!

Folks are liking patch in #37! :)

Just tried patch #37 on 7.x-3.17 and works as advertised.

seeking attention.

Bump (for additional attention). :)

Re-rolled #37 against 7.x-3.x-dev.

Not sure why testbot is complaining.

reuploaded to trigger testbot, all tests are passed.

Sweet! Back to RTBC? Or good to get in?

I'm still getting this error with patch from #55, screenshot attached. I'm using views 7.x-3.20 with search_api.

Attached a similar patch to check for the 'empty' and 'not empty' operator earlier.

Please ignore patch #57, included fix for other issues.

Back on track
Works for 7.x-3.20
Next release?

I can confirm that #58 fixes the issue.

Confirm #58 working fine.

Cool! Anyone else try this out with success? Is two enough for RTBC? :)

Still good on our end.

Committed. Thank you.