Views UI should offer a 'Treat NULL values as FALSE' on boolean field filtering to expose the already existing code path for handling this

All the needed logic is in the boolean filter handler, there is just no way to activate it through the UI, only through altering the plugin definition of the field. So adding a way to activate this in the UI sounds useful.

      if ($this->accept_null) {
        if ($query_operator == static::EQUAL) {
          $condition = (new Condition('OR'))
            ->condition($field, 0, $query_operator)
            ->isNull($field);
        }
        else {
          $condition = (new Condition('AND'))
            ->condition($field, 0, $query_operator)
            ->isNotNull($field);
        }
        $this->query->addWhere($this->options['group'], $condition);
      }

So this ticket probably needs to be closed, and one needs to be opened under views.ui to request a null/not null flag. There may already be something like that.

That said, here's a work around for people who need to get something working now. In the work around below I have a reviewed flag on my comments and a for that flag on my comments view. Here's the code I'm using so that if reviewed is set to false it also includes nulls.

function newport_rest_views_pre_build(ViewExecutable $view) {
  if ($view->storage->id() == 'comments') {
    // If reviewed is set to false then we should include NULLs.
    if ($view->filter['field_reviewed_value']->value == 0) {
      $view->filter['field_reviewed_value']->accept_null = TRUE;
    }
  }
}

Remember you can always run a var_dump on your $view variable to find out your id's, current_displays, and field names/values. You also need to be careful with this approach and make sure you're only altering the views you intend to alter.

Rather than closing this ticket I've moved it over to the views_ui module.

@kier.heyl
Thx for quick solution :) Work perfect!

I had exactly the same issue, however if your case allows it. Setting the field to the value equals false, works.

Same issue, but this time added a boolean field to the content type long after 1000s of nodes had been created.

Not every node is being updated with the boolean value in this case (too time consuming).

As per @iampuma setting the field to value equals false, or value != true does not work in the UI... It seems views can't find the boolean field data in the non-updated nodes and as a result excludes these.

Solution was #3.

A UI fix could be to allow filtering on a null value within views_ui, allowing the possibility of grouping filters with an OR (true/false OR null)

I agree having a null/not null option in Views UI would be really helpful.

If this is a bug, it'll have to go into 8.5, so I'm updating that now. If it's considered a new feature, it should be 8.6.

Have just run into this issue myself. I have a content type with just over 20 records, added a new boolean field, edited one record to set the new field to TRUE, leaving all other records untouched. Views doesn't seem to be able to work with the new field correctly at all: if I add either "is FALSE" or "is not TRUE" I get no records at all. Tried #3 but it didn't cure it. This is with Drupal core 8.3.2

OK, I'm updating the IS in the hopes of simplifying things and getting this some attention. And since the consensus has been getting this in the UI, I think that's reasonably a feature request, so changing that and consequently updating the version.

- Remove extra modification.
- break once the options is found.

Im having this issue right now!. I think i will use for now another field like number or something else. In my case I want to flag a node for Sticky Content, creating that boolean just make all the old content without a valule. So when I use views and filter the content, all the old content just dissapears because it have a null there.

Hope to find a solution :)

#17 worked well for me, I would suggest maybe simplifying the wording to something like: "Include Null" - "if flagged then null will be included"

Worth noting that this will not work with 'Is not equal to' with value of 'True', only works with 'Is equal to' value of 'False'. Created a separate issue for that as I think these can be handled independently.

#17 worked for me. I will try the plugin from #3.

I ran into the issue as well and the patch worked great. I'm using "Is equal to False" and checked "Accept NULL". Having this option allows me to introduce a new feature in my display form without having to have users go back and resave forms or automate marking off the field as false.

Here is a screenshot for reference (some parts in French):

Reroll against 8.7.10.

Todo:

• The new setting needs a test
• The new setting needs a config change
• The config change needs an upgrade path
• The upgrade path needs an upgrade path test

Can this be done more generically for all field types? If so, we should close this in favour of #3073362: Allow for exposed filter options "Empty" and "Not empty" in the selection list to filter on (un)set values.

addressed my own feedback. added test, added upgrade path, added upgrade path test, added config schema

@Lendude: Thoughts on #29?

Last patch failed to apply , re-rolling patch , kindly review.

Patch #33 works as expected:

on Drupal 9 installation:
- created 10 nodes
- added a boolean field named "field_is_trending" (value of that field is NULL)
- created a view with filtering by "field_is_trending == FALSE"

Before the patch: view returns no results

After the patch: a new option becomes available "Accept NULL"
if "Accept NULL" flag is set to TRUE: "OR ( field_is_trending IS NULL)" added to SQL query and all nodes are returned
if "Accept NULL" flag is set to FALSE: nothing is added to SQL query and NO nodes are returned

- updated 3 nodes set field_is_trending to TRUE, 2 nodes field_is_trending to FALSE

if "Accept NULL" flag is set to TRUE: OR ( field_is_trending IS NULL) added to SQL query and 7 nodes are returned
if "Accept NULL" flag is set to FALSE: nothing is added to SQL query and 2 nodes are returned

if view has "field_is_trending == TRUE" or "field_is_trending != TRUE or "field_is_trending != FALSE" value of "Accept NULL" is not affecting the query (there's an issue for it https://www.drupal.org/project/drupal/issues/3045787)

New views configuration value is exported to config yml as expected.

PS: how to backport it to D8?

Taking another look at this:

1. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -96,12 +96,14 @@ public function init(ViewExecutable $view, DisplayPluginBase $display, array &$o
   -    if (isset($this->definition['accept null'])) {
   -      $this->accept_null = (bool) $this->definition['accept null'];
   -    }
   -    elseif (isset($this->definition['accept_null'])) {
   -      $this->accept_null = (bool) $this->definition['accept_null'];
   -    }
   +    foreach (['accept_null', 'accept null'] as $key) {
   +      foreach ([$this->options, $this->definition] as $array) {
   +        if (isset($array[$key])) {
   +          $this->accept_null = (bool) $array[$key];
   +          break;
   +        }
   +      }
   +     }
   
   @@ -139,11 +141,25 @@ public function getValueOptions() {
   -    $options['value']['default'] = FALSE;
   

   These changes are unrelated changes and need to be reverted. They are clean up and out of scope.

2. +++ b/core/modules/views/views.post_update.php
   @@ -51,3 +52,33 @@ function views_post_update_field_names_for_multivalue_fields(&$sandbox = NULL) {
   +function views_post_update_boolean_filter_accept_null(&$sandbox = NULL) {
   

   We should move this logic to \Drupal\views\ViewsConfigUpdater (yeah I know I'm criticising my own code :))

@colan to #29: I've updated the title to better reflect the change here. We are exposing existing logic in the UI, where as the other issue would need to add logic. So this is much less invasive I feel.

Oh and I forgot: @jannakha thanks for taking a look at this issue and the great review!

The title and issue summary (outside of the code in the summary) is about implementing the "Is empty (NULL) / Is not empty (NOT NULL)" filter operations, but the patches here focus on implementing the accept null definition option, which is not the same thing.

Per the documentation of the filter: "- accept null: Treat a NULL value as false." So this flag would be used in conjunction with the "Is equal to / Is not equal to" filters, but this doesn't help us actually filter empty and not-empty values.

Here I've attached a separate track of work adding these operators. It is effective when the filter is not exposed, but the exposed part needs more work.

• Combines #33 and #37
• Addresses #35.1
• Adds test for empty /not empty filter

I tried applying this patch to a Drupal 8.9 site to no avail. I went ahead and re-rolled it, although I'm not sure if I should upload it until the 9.1 version is complete. Happy to do whatever is requested.

The patch works as advertised :)

Also, ::wave:: @akalata!

-mike

Worth re-rolling for 8.9

Okay hopefully I re-rolled it correctly this time...

Addresses #35.2 and a minor coding standard issue from #38

Hi,

After I receive the following error:

Drush Commandline Tool 10.3.5
-------- ------------------------- ------------- -----------------------
Module Update ID Type Description
-------- ------------------------- ------------- -----------------------
views boolean_filter_accept_n post-update Update boolean filter
ull settings.
-------- ------------------------- ------------- -----------------------

// Do you wish to run the specified pending updates?: yes.

> [notice] Update started: views_post_update_boolean_filter_accept_null
> [error] TypeError: Argument 1 passed to Drupal\views\ViewsConfigUpdater::processEntityLinkUrlHandler() must be of the type array, null given, called in /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php on line 122 in Drupal\views\ViewsConfigUpdater->processEntityLinkUrlHandler() (line 205 of /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php) #0 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php(122): Drupal\views\ViewsConfigUpdater->processEntityLinkUrlHandler(NULL, 'field')
> #1 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php(161): Drupal\views\ViewsConfigUpdater->Drupal\views\{closure}(NULL, 'field', 'nid', 'block_2')
> #2 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php(135): Drupal\views\ViewsConfigUpdater->processDisplayHandlers(Object(Drupal\views\Entity\View), false, Object(Closure))
> #3 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/views.module(853): Drupal\views\ViewsConfigUpdater->updateAll(Object(Drupal\views\Entity\View))
> #4 [internal function]: views_view_presave(Object(Drupal\views\Entity\View))
> #5 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(403): call_user_func_array('views_view_pres...', Array)
> #6 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(347): Drupal\Core\Extension\ModuleHandler->invokeAll('view_presave', Array)
> #7 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(500): Drupal\Core\Config\Entity\ConfigEntityStorage->invokeHook('presave', Object(Drupal\views\Entity\View))
> #8 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(454): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\views\Entity\View))
> #9 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(263): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\views\Entity\View))
> #10 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Entity/EntityBase.php(395): Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object(Drupal\views\Entity\View))
> #11 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(616): Drupal\Core\Entity\EntityBase->save()
> #12 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityUpdater.php(130): Drupal\Core\Config\Entity\ConfigEntityBase->save()
> #13 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/views.post_update.php(409): Drupal\Core\Config\Entity\ConfigEntityUpdater->update(Array, 'view', Object(Closure))
> #14 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(314): views_post_update_boolean_filter_accept_null(Array)
> #15 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/includes/batch.inc(254): Drush\Commands\core\UpdateDBCommands::updateDoOnePostUpdate('views_post_upda...', Object(DrushBatchContext))
> #16 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/includes/batch.inc(199): _drush_batch_worker()
> #17 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/includes/batch.inc(100): _drush_batch_command('220')
> #18 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(168): drush_batch_command('220')
> #19 [internal function]: Drush\Commands\core\UpdateDBCommands->process('220', Array)
> #20 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
> #21 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #22 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #23 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(302): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #24 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #25 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Application.php(1005): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #26 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Application.php(255): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #27 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #28 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #29 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
> #30 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
> #31 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/drush(4): require('/var/www/vhosts...')
> #32 {main}.
> TypeError: Argument 1 passed to Drupal\views\ViewsConfigUpdater::processEntityLinkUrlHandler() must be of the type array, null given, called in /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php on line 122 in /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php on line 205 #0 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php(122): Drupal\views\ViewsConfigUpdater->processEntityLinkUrlHandler(NULL, 'field')
> #1 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php(161): Drupal\views\ViewsConfigUpdater->Drupal\views\{closure}(NULL, 'field', 'nid', 'block_2')
> #2 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/src/ViewsConfigUpdater.php(135): Drupal\views\ViewsConfigUpdater->processDisplayHandlers(Object(Drupal\views\Entity\View), false, Object(Closure))
> #3 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/views.module(853): Drupal\views\ViewsConfigUpdater->updateAll(Object(Drupal\views\Entity\View))
> #4 [internal function]: views_view_presave(Object(Drupal\views\Entity\View))
> #5 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(403): call_user_func_array('views_view_pres...', Array)
> #6 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(347): Drupal\Core\Extension\ModuleHandler->invokeAll('view_presave', Array)
> #7 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(500): Drupal\Core\Config\Entity\ConfigEntityStorage->invokeHook('presave', Object(Drupal\views\Entity\View))
> #8 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(454): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\views\Entity\View))
> #9 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(263): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\views\Entity\View))
> #10 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Entity/EntityBase.php(395): Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object(Drupal\views\Entity\View))
> #11 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(616): Drupal\Core\Entity\EntityBase->save()
> #12 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityUpdater.php(130): Drupal\Core\Config\Entity\ConfigEntityBase->save()
> #13 /var/www/vhosts/bytheways.net/prod.bytheways.net/web/core/modules/views/views.post_update.php(409): Drupal\Core\Config\Entity\ConfigEntityUpdater->update(Array, 'view', Object(Closure))
> #14 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(314): views_post_update_boolean_filter_accept_null(Array)
> #15 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/includes/batch.inc(254): Drush\Commands\core\UpdateDBCommands::updateDoOnePostUpdate('views_post_upda...', Object(DrushBatchContext))
> #16 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/includes/batch.inc(199): _drush_batch_worker()
> #17 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/includes/batch.inc(100): _drush_batch_command('220')
> #18 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(168): drush_batch_command('220')
> #19 [internal function]: Drush\Commands\core\UpdateDBCommands->process('220', Array)
> #20 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
> #21 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #22 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #23 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(302): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #24 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #25 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Application.php(1005): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #26 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Application.php(255): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #27 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #28 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #29 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
> #30 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
> #31 /var/www/vhosts/bytheways.net/prod.bytheways.net/vendor/drush/drush/drush(4): require('/var/www/vhosts...')
> #32 {main}
> [warning] Drush command terminated abnormally.

Can someone support me in solving the issue?

Thanks,
José

There's still work to do on views_post_update_boolean_filter_accept_null, running update causes fatal error:

Error: Call to a member function getConfigDependencyKey() on null in Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid->calculateDependencies() (line 421 of /var/www/html/docroot/core/modules/taxonomy/src/Plugin/views/filter/TaxonomyIndexTid.php)

I'm not experiencing the issues from #47 and #49 so unsure how to fix them.
Attached is a straight rerol from #46 against 9.3.0

Patch from #50 container a small error in the post_update file, corrected in the attached patch.

Thanks, everybody, I am very excited to try #51 tonight or Monday.

Do y'all think it's a done-deal (as much as anything is) that the approach on this thread will be accepted, vs. the perspective/approach on these two issues? --
#3036954: Boolean field filter "Is not equals to"
#2862828: Boolean field filtering does not work when no values are set

I realize those two issues are and/or may be marked duplicate in favor of this one, but people are still working on them, and, reading the threads nothing felt SUPER definitive to me, so I'm gauging opinions over here 😁 (Also, maybe they're not as mutually exclusive (with this approach here) as they appear to me.)

Seems to work great. This is not a real review, just some random comments:

+
+    // if the definition allows for the empty operator, add it.
+    if (!empty($this->definition['allow empty'])) {
+      $operators += [

"if" should be uppercase.

+    foreach (['accept_null', 'accept null'] as $key) {
+      foreach ([$this->options, $this->definition] as $array) {
+        if (isset($array[$key])) {
+          $this->accept_null = (bool) $array[$key];
+          break;
+        }
+      }

Not sure why the multiple combinations need to be checked (maybe a comment to explain it would help?). Also, using a single if clause with 3 || operators would make this more readable IMHO.

+      if (empty($this->options['expose']['use_operator']) || empty($this->options['expose']['operator_id'])) {
+        // exposed and locked.
+        $which = in_array($this->operator, $this->operatorValues(1)) ? 'value' : 'none';
+      }

"exposed" should be uppercase. Not sure if the comment is necessary.

+    $form['accept_null'] = [
+      '#type' => 'checkbox',
+      '#title' => $this->t('Accept "NULL"'),
+      '#description' => $this->t('Treat a NULL value as false.'),
+      '#default_value' => $this->accept_null,
+    ];

Looking at the UI text, it seems that putting NULL without quotes would be more consistent. AFAICS, we don't have other strings containing "NULL" (with quotes) in the Drupal codebase. Also, ideally, I think the checkbox should be positioned higher in the list, maybe before the User Roles or even higher (before the option to expose the operator?). I think this is an important option and should more visible, but I don't feel strong about it. Another thing is whether it should be enabled as default (ideally yes, IMHO, as the behaviour would be more intuitive, but maybe not as this would introduce breaking changes).

I also note that the User interface changes written in the issue description does not match the patch behaviour, but I imagine it may be outdated.

Patch works perfectly for us on 9.2.16 and 9.3.12 sites, and it applies cleanly on 9.4.x and 9.5.x.

Small thing I came across (and maybe doesn't matter b/c it's just a patch file thing?): I see a couple extra lines at lines 616-617 in the patch file itself (git apply patchname.patch complained about these lines).

Attached is a version of #51 without those two lines -- if this tweak is an unnecessary nit, never mind!

Also, I just noted this new option is not available in group filters.

I guess this could be implemented separately, in a follow-up ticket.

Thanks to everyone who has worked on this. I have applied the patch in #51 to my D9.3.x project and I'm seeing something odd.

The following screenshots are logically equivalent but the one where the filter is "not equals true" does not appear to be working correctly. It's filtering out content where the boolean is not set.

This works perfectly:

This does not work:

I don't have time to dig in and see what's going on. But the two configurations above are logically equivalent and should have the same effect. I think I have to set this back to NW unfortunately.

@danflanagan8 Thank you! -- if you have time, could you share the query your view is running (or both of them)? I feel like this info could be helpful, if possible.

Good idea, @alisonjo315! I've run into this on two very separate client projects in the last couple years, and I'd love to help get this figured out.

I'm starting from scratch on a test site now.
1. I've done a standard install on D9.4.x (my first since the beautiful Olivero became the theme).
2. I created two articles called "Checked Boolean" and "Boolean Not Checked".
3. I added a boolean field called field_my_test_boolean to Articles.
4. I edited "Checked Boolean" and checked the boolean field.
5. I created a View with a filter on field_my_test_boolean.

At this point, as described in the original IS, my article "Boolean Not Checked" will never get returned by the View, since the value of field_my_test_boolean is null.

6. I re-rolled the patch from #54 (attached) and applied it.
7. I configure the filter for field_my_test_boolean with "Is equal to FALSE" with the "Accept Null" checked. This correctly returns my article "Boolean Not Checked". Woohoo! The query is:

SELECT "node_field_data"."created" AS "node_field_data_created", "node_field_data"."nid" AS "nid"
FROM
{node_field_data} "node_field_data"
LEFT JOIN {node__field_my_test_boolean} "node__field_my_test_boolean" ON node_field_data.nid = node__field_my_test_boolean.entity_id AND node__field_my_test_boolean.deleted = '0'
WHERE ("node_field_data"."status" = '1') AND ("node_field_data"."type" IN ('article')) AND (("node__field_my_test_boolean"."field_my_test_boolean_value" = '0') OR ("node__field_my_test_boolean"."field_my_test_boolean_value" IS NULL))
ORDER BY "node_field_data_created" DESC
LIMIT 11 OFFSET 0

8. Now I reconfigure the filter to be "Is not equal to TRUE" with the "Accept Null" still checked. This is logically identical (right!?) but now I don't get any results. Here is the query:

SELECT "node_field_data"."created" AS "node_field_data_created", "node_field_data"."nid" AS "nid"
FROM
{node_field_data} "node_field_data"
LEFT JOIN {node__field_my_test_boolean} "node__field_my_test_boolean" ON node_field_data.nid = node__field_my_test_boolean.entity_id AND node__field_my_test_boolean.deleted = '0'
WHERE ("node_field_data"."status" = '1') AND ("node_field_data"."type" IN ('article')) AND ("node__field_my_test_boolean"."field_my_test_boolean_value" <> '1')
ORDER BY "node_field_data_created" DESC
LIMIT 11 OFFSET 0

The WHERE clause in step 8 does not mention NULL at all. Checking the "Accept Null (Treat a NULL value as false.)" box does not appear to affect the query if we TRUE selected at the value we compare to.

Hopefully this helps!

I'll leave this at NR to see if the patch applies ok. But it should be in NW probably.

Thank you!

And, SHOOT I did the "didn't reload old tab with old issue status" thing 😖 I also accidentally changed it to 9.4.x.

Is the reroll meant for 9.5.x?

(I'm not going to change anything right now, we'll see how the tests go, but, sorry about that!)

Hmm, I just noticed that there's a related issue #3045787: Views Boolean "Accept null" does not work if Operator set to "Is not equal to" with value "True" that was created as a spin-off of this issue in comment #23.

I disagree that the issue pointed out in #23 and described in detail in #59 should be solved in a separate issue. If we take the time to add this "Accept Null" to the UI we should make sure it works! Maybe there's a compelling reason to handle that separately though. I'm no expert on the code inside views/views_ui by any means.

Is the reroll meant for 9.5.x?

No, it's for 9.4.x. It just addresses the "patch failed to apply" error that #54 experienced.

error: patch failed: core/modules/views/src/ViewsConfigUpdater.php:141
error: core/modules/views/src/ViewsConfigUpdater.php: patch does not apply

#61: I missed that, too, thanks for pointing it out and recapping.

(#62 -- gotcha, thank you!)

"Accept null" doesn't seem to work with Search API, because SearchApiQuery doesn't provide a getConnection method. Is there any way we could fix or work around this?

Error: Call to undefined method Drupal\search_api\Plugin\views\query\SearchApiQuery::getConnection() in Drupal\views\Plugin\views\filter\BooleanOperator->queryOpBoolean() (line 319 of core/modules/views/src/Plugin/views/filter/BooleanOperator.php).

EDIT: I believe this would need to be fixed separately in #2871814: views boolean filter with 'not equal to TRUE' doesn't return empty fields by overriding the queryOpBoolean method.

Fixed a few tests. Still needs work for #57

Attached patch fixes the last test failure. Still needs work for #57

#57 To prevent scope creep, I limited the change to exposing the existing options to treat NULL values as False. To prevent confusion the option is now only display when the value is set to False.

See screen capture below:

+1 to #71, that looks much clearer

Looking at this now, I'm not overly thrilled about the scope creep of the empty/not empty operators, to me that should have been a separate change really, but we have test coverage for it, so, hmmm. I would not be opposed to taking the new operators out of this issue and moving them to a new one.

Bit of nitpicking, but #57 is something that needs to be looked into

1. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -105,13 +124,17 @@ public function init(ViewExecutable $view, DisplayPluginBase $display, array &$o
   +    foreach (['accept_null', 'accept null'] as $key) {
   +      foreach ([$this->options, $this->definition] as $array) {
   

   So are we supporting 4 ways of setting this? We should probably not have so many ways of doing it, but if we must should we add tests for it?

2. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -148,12 +171,14 @@ public function getValueOptions() {
   -    $options['value']['default'] = FALSE;
   +    $options['accept_null']['default'] = FALSE;
   

   Are we removing this default value for a reason?

3. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -166,14 +191,37 @@ protected function valueForm(&$form, FormStateInterface $form_state) {
   +    $which = 'all';
   

   '$which' doesn't tell me anything, can we get a clearer name and/or comment what is going on here?

4. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -166,14 +191,37 @@ protected function valueForm(&$form, FormStateInterface $form_state) {
   +        // exposed and locked.
   

   needs to be a full sentence

5. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -274,4 +341,26 @@ protected function queryOpBoolean($field, $query_operator = self::EQUAL) {
   +  protected function opEmpty($field) {
   ...
   +  protected function operatorValues($values = 1) {
   

   These need docblocks

6. +++ b/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
   @@ -274,4 +341,26 @@ protected function queryOpBoolean($field, $query_operator = self::EQUAL) {
   +    if ($this->operator == 'empty') {
   

   == can be ===

#72

I would not be opposed to taking the new operators out of this issue and moving them to a new one.

Filed #3322402: Add 'Is empty (NULL)' and 'Is not empty (NOT NULL)' operators to boolean field filtering for a clearer issue scope.

Updated the title to match the direction here.

patch 71 works well! Thanks.

Lendude responded with a 'I'm not overly thrilled' and a 'hmm, not sure'.

It makes sense to allow null values to be considered as false for exposed filters. Imagine the scenario, you add a new boolean field to a node and want to be able to filter on it. Rather than save every node and mess up metadata the above core patch does the job cleanly.

What's remaining to do for this to get accepted and committed? If we resolve the nits in #72 , is that enough to get this in?

Well most importantly, we need a patch that strips out the scope creep that got spun off into #3322402: Add 'Is empty (NULL)' and 'Is not empty (NOT NULL)' operators to boolean field filtering (and looking at the feedback there that was a good idea).

Once we have a slimmed down patch, let's see what is left of the nits and if we have enough test coverage for what is left.

Still not sold on this being the right fix for this problem, but people seem to want this, so ¯\_(ツ)_/¯
The only reason I was for this since the boolean filter already had logic for this and it seemed easy to just expose that logic. This being Views, of course it wasn't easy.....

This is a bandaid solution for a bigger problem, to me, https://www.drupal.org/project/field_defaults is the right solution for now.
See my reasoning/rant in #2862828: Boolean field filtering does not work when no values are set.

patch 71 works, ty!

We had exactly this case:
It makes sense to allow null values to be considered as false for exposed filters. Imagine the scenario, you add a new boolean field to a node and want to be able to filter on it. Rather than save every node and mess up metadata the above core patch does the job cleanly.

This was another solution:
https://drupal.stackexchange.com/questions/288232/filter-on-boolean-with...

The patch works, but causes an unexpected change to the admin/content view (see screenshot).

Rerolled the patch for 10.0.x, and created an issue fork for it as well.

Have not yet reviewed but MR caused some failures.

Also MR should be updated for 11.x please.

Have not reviewed or tested yet.

In case someone needs a patch against a 10.1.x version of the Drupal Core.

Y'all broke my unit tests! This corrects that the Views filter schema was updated but not the sort schema.

For anyone playing along:

    Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for
    views.view.frontpage with the following errors:
    views.view.frontpage:display.default.display_options.sorts.sticky.accept_null
    missing schema

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.