Posthumously we have been required to add a boolean "hide from front end" field to our article content type as a number of articles need to be hidden from view yet still available to search engines. We have subsequently found that due to the field not having been set any combination of filtering on this field results in no articles being shown rather than just the ones which have been specifically ticked.

My thinking is that if someone was to choose "Is not equal to True" then this should only hide the fields which have been ticked whereas it is also hiding the articles which have yet to have this field set.

This to me looks to be a bug, so hoping someone can help with this?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

leovw created an issue. See original summary.

cilefen’s picture

Title: Adding fields to filter with posthumously » Boolean field filtering does not work when no values are set
cilefen’s picture

Assigned: leovw » Unassigned

When you assign yourself to an issue, the message is "I am working on this". Based on the issue summary, I don't think this is the intent.

leovw’s picture

Very true! Yes apologies

leovw’s picture

Priority: Normal » Major

Anybody looking into this? This is hindering me severely!

mjchadwick’s picture

@leovw I tried to duplicate this issue the following way:

  1. Have at least on existing Article node, and then create at least one new Article node
  2. Create a new Boolean field on the Article content type called "Hide From Front End" (not required, default unchecked)
  3. Create a view that displays Article nodes, but create filter on "Hide From Front End != True"
  4. Display view

Unfortunately, I was not able to replicate the behavior on 8.4-dev. Existing Article nodes with the Boolean field never touched still show up, and only the one Article node I checked the Boolean field on is hidden.

Either this is a more specific issue, or I've missed something. Please advise!

liorf’s picture

I also encountered the described problem in version 8.3.0
In the meantime I am using a field of type List (interger) to reach the required functionality.

Lendude’s picture

Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs steps to reproduce

Writing an update hook to set the field values for the missing values makes more sense to me as a solution here. That way, you control what the default value should be, not have Views make some sort of assumption about what to do with NULL values.

According to #6 we need more accurate steps to reproduce this on a clean install (the steps in #6 is also what I would expect to reproduce this according to the IS), so setting to 'needs more info' for that.

This also doesn't feel major so setting back to normal.

leovw’s picture

Hi - I have a site of about 500 nodes and I can confirm that I am still experiencing the same behaviour.

The steps are:

1) The article node was created a while ago and now consists of about 500 nodes.
2) Some of this content we decided we no longer wanted visible on various views so I created a boolean field: "Show on frontpage".
3) I then adjusted a view with the filter using "Show on frontpage" with it set to: is not equal to True.
4) I then looked at the view which was now empty.
5) I saved a couple of articles without adjusting the field and they then showed up.

I am presuming that this behaviour isn't how it should work or otherwise there should be a filterable option available for if a field exists on the node?

I can confirm that whilst not as elegant the list (integer) solution does indeed work thank you liorf

Karol Haltenberger’s picture

I can confirm, this doesn't work as expected...at least not as I expected it to work.

My expectations - and those of the OP I imagine - were that it would filter like this:

1 Equals + TRUE = all entities HAVING a field value of TRUE
2 Equals + FALSE = all entities HAVING a field value of FALSE
3 Does not equal + TRUE = all entities NOT HAVING a field value of TRUE including empty field values
4 Does not equal + FALSE = all entities NOT HAVING a field value of FALSE including empty field values

Unfortunately the last two conditions do not simply translate to a '<>' or '!=' operator in SQL (I'm not familiar with other query languages) otherwise it would (almost) all work.

I've looked at /core/modules/views/src/Plugin/views/filter/BooleanOperator.php and there is some logic involving NULL/non-existent values, but:
1. it only works if the selected value is FALSE, meaning that it sort of works like condition 2 with empty fields and 4 without them
2. it only works if this "accept_null" property is TRUE...which it is not and I don't see how it is supposed to be set...it is not being set anywhere in the drupal source code ¯\_(⊙︿⊙)_/¯

  protected function queryOpBoolean($field, $query_operator = EQUAL) {
    if (empty($this->value)) {
      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);
      }
      else {
        $this->query->addWhere($this->options['group'], $field, 0, $query_operator);
      }
    }
    else {
      if (!empty($this->definition['use_equal'])) {
        // Forces an '=' operator instead of a '<>' for performance reasons.
        if ($query_operator == static::EQUAL) {
          $this->query->addWhere($this->options['group'], $field, 1, static::EQUAL);
        }
        else {
          $this->query->addWhere($this->options['group'], $field, 0, static::EQUAL);
        }
      }
      else {
        $this->query->addWhere($this->options['group'], $field, 1, $query_operator);
      }
    }
  }

Setting this property to TRUE allows the distinction between TRUE and FALSE OR NULL (opt-in).
Maybe this is an option that got lost at some point, I don't know.

I'll just modify core (and accept ever lasting hellfire for it), hoping that a better solution comes along.

Karol Haltenberger’s picture

On second thought I agree with Lendude.
The newly created field should create the missing field values.

joachim’s picture

> The newly created field should create the missing field values.

Except that creating a new field is a task easily accomplished by a site admin, whereas populating it with values for existing nodes is not.

Regarding how to reproduce, this step needs to be changed:

> Create a view that displays Article nodes, but create filter on "Hide From Front End != True"

If the filter is set to "Hide From Front End = False", then you get the problem.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

wturrell’s picture

xamount’s picture

I can confirm that the same effect happens for me as exactly described in comment #9.

Will have to use list text field instead to get around this problem.

Drupal version: 8.6.10

JurgenR’s picture

Version: 8.6.x-dev » 8.7.x-dev
Status: Postponed (maintainer needs more info) » Active

I have a similar issue as described in #9.
On a database with about 200 articles, I've added a 'Restricted access' flag and only want to show the articles without this flag in a view.

The filter is set Restricted access is not equal to TRUE, so it seems to me that NULL values should be included in the view.
This is not the case.

Steps to reproduce:on a clean install:

  1. Create 500 articles with devel generate
  2. Add a new boolean 'Restricted access' field on Article content type
  3. Create a view with filter 'Restricted access', operator = 'Is not equal to' and 'Restricted access' = TRUE
  4. No results available in the preview
tetranz’s picture

Status: Active » Needs review
FileSize
1.53 KB
10.69 KB

Here's a patch. Maybe just as a starting point. It adds a checkbox to allow null to be evaluated as false.

New checkbox

As was noted in #10, the backend code already exists for this but does not appear to be used. It's also a bit weird in the init() method where isset($this->definition['accept null']) is evaluated twice. I've changed the elseif to look at the options.

I don't see anywhere where $this->definition['accept null'] can be set. I guess if it is set then I should not show the checkbox. Maybe someone else can shed some light on this.

I know this will probably need some tests but let's see how this goes first.

It's not perfect (or perhaps slightly confusing) because it only does anything if the selected value of the filter is false. Someone could reasonably assume that this will also change "Is not equal to True" but it doesn't. That means it doesn't exactly satisfy the issue as originally stated but it does provide a solution to achieve the desired and I think reasonably intuitive result.

I guess "not equal to true" is fixable. If the value is true and the operator is "not equal to" then the query condition needs "OR field IS NULL" added.

Maybe the checkbox needs a description. I started doing that but none of the other form elements on that form have descriptions so it looked a little out of place.

Status: Needs review » Needs work

The last submitted patch, 19: boolean-no-value-2862828-19.patch, failed testing. View results

tetranz’s picture

Status: Needs work » Needs review
FileSize
2.05 KB
536 bytes

Adding config schema,

tetranz’s picture

I think this will need a hook_update for the schema change. I need to research that a little.

I'd like to get all combinations of "is equal to" and "is not equal to" working correctly.

tetranz’s picture

This gets every combination of "is equal to", "is not equal to", "evaluate null as false" and "use equals" working as it I think is reasonably expected.

It's awkward, messy code with lots of branching. Maybe I'm missing a good way to tidy it up.

I don't think this needs an update hook for the schema change as I initially thought. Old views config which are missing the new properly still validate correctly.

I know it needs tests. I think I'll wait for comments before diving into that.

slefevre@ccad.edu’s picture

I recently ran into this issue, too. With all the branching and messy code, wouldn't the optimal solution be to auto-populate the field upon creation or attachment? Then views filters Just Work out of the box.

tetranz’s picture

Yes, updating the field with non-null data is certainly one option.

That said, someone without database knowledge doesn't necessarily know the difference between false and null and a checkbox looks the same for both values. Also, that requires a hook_update or similar and updating thousands of entities can be a heavy operation.

I think it's a reasonable non-technical expectation to see an unchecked checkbox and expect it to behave as false. A boolean null does effectively behave as false(y) if you retrieve one entity and do something with the value.

Anyway, I did this because I had some time available. It's here if anyone wants it.

Lendude’s picture

Yeah I still feel the right solution for this is #1919834: Field instance got no default value when created in field UI, when I add a boolean field I expect the field to respect the default value for existing content. So in Views this should translate to NULL == 'default value set in Field UI', so false or true depending on the field setting. That just doesn't sound like something we should fix in Views.

tetranz’s picture

@Lendude, I looked at that other issue. I think I understand it and what you're saying. I think it's saying that when you access an entity via the API, if a properly is not saved in the database, the API should return the default value rather than null / nothing at all.

That makes sense. I haven't checked if core does that but ... it doesn't help this problem with Views because Views does the filtering at the SQL level. It doesn't retrieve the entity and then check the field value.

It still needs to come down to something like

WHERE (some_column = value OR some_column IS NULL).

The only two ways I can see to fix this are something like that in SQL or physically populating the database when a field is added to an entity.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.9 was released on November 6 and is the final full bugfix release for the Drupal 8.7.x series. Drupal 8.7.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.8.0 on December 4, 2019. (Drupal 8.8.0-beta1 is available for testing.)

Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

dqd’s picture

@tetranz thanks for the patches!

I think previous comment nailed it partly. Since Views pretends to parse SQL directly, we can assume that Views still needs an own solution for this issue. The discussion about writing default value in existing field instances from the other core issue #1919834: Field instance got no default value when created in field UI can become a very long one and can change over the years in many directions, since this involves a lot other things. And since this filter is assuming that the user understands the basics of IS NOT TRUE, otherwise the filter wouldn't have been labeled like this, we can definitely set this feature to be partly confusing in the moment. And this means this issue has a raison d'être.

Logically looked at it, IS NOT TRUE includes everything but TRUE, and EMPTY is part of this inclusion. Until someone can show me a useful and more common used scenario than this, where this "assumption" is contra-productive or would cause issues, I can not see the reasons for this default behaviour in the moment.

I would definitely vote for an additional option to accept and interprete EMPTY as IS NOT TRUE on "is not equal to TRUE" like drafted in the patch @ #19 - to prevent all this work-arounds arising from this issue here.

For the stated core issue before, there is a module for that: https://www.drupal.org/project/field_defaults

jbitdrop’s picture

+1 for #29 - I agree with vote for

additional option to accept EMPTY IS NOT TRUE
dqd’s picture

Possibly related to my thoughts on this ...

Lendude’s picture

Still -1 to 'EMPTY IS NOT TRUE', the counter use case is where a boolean field is 'checked' by default. In that case, the empty value should evaluate to TRUE.

The right solution would be "NULL == 'value that was set as default in the Field UI'". But, this is not something specific to the boolean filter/field, this goes for all filters/fields that set a default value, so if we add this to boolean filters, why not to all the other filters too?

#1919834: Field instance got no default value when created in field UI or https://www.drupal.org/project/field_defaults (thanks for that link!) are the right solutions for this. The solution here is a small band aid on one symptom of a much larger issue. And one that we would need to revert once the actual issue is resolved.

maskedjellybean’s picture

This is certainly a "WTF Drupal" bug. I agree that either the value of the field should be set to the default value on existing nodes when the field is created, or null should be evaluated as equal to the default value.

If you want to go with the update hook solution instead of patching core, it would look something like this:

/**
 * Re-save all Service Detail nodes and set new boolean field to false.
 */
function oh_services_update_8001() {
  // Get an array of all Service Detail node ids.
  $service_detail_nids = \Drupal::entityQuery('node')
    ->condition('type', 'service_detail')
    ->execute();

  // Load all the Service Detail nodes.
  $service_details = Node::loadMultiple($service_detail_nids);
  foreach ($service_details as $service_detail) {
    $service_detail->get('field_exclude_from_service_line')->setValue(false);
    $service_detail->save();
  }
}

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

developer-rocha’s picture

Same problem with Drupal 8.8.8
Solved with #23 patch.

Thank you.

markie’s picture

Status: Needs review » Reviewed & tested by the community

Marking as RTBC since I've been using #23 in production for some time and there are other people using it as well. Thanks

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Thanks for filing this bug report and for fixing the issue. Bug fixing is very valuable. In order to commit a bug fix, we need an automated test to prove that we've fixed the bug and ensure that we don't break it again in the future. For more information about writing tests in Drupal, see the following links:

  1. https://www.drupal.org/docs/testing/phpunit-in-drupal/phpunit-javascript...
  2. https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/9.1.x

Also as we're adding a new option to a view we need an update path for existing views to have the new option set to the default value.

Plus @Lendude is a views sub system maintainer so the comment in #32 needs answering.

dqd’s picture

100% agree on #38 and #32 with 2 thoughts added. @Lendude thanks for your thougths on it.

Still -1 to 'EMPTY IS NOT TRUE', the counter use case is where a boolean field is 'checked' by default. In that case, the empty value should evaluate to TRUE.

I somewhat stutter on this: Why do we assume that a checked boolean checkbox by default is an empty field value? Do we not write default values into the column of field when a new item with field has been created? From my understanding any default field value should be written and is not empty unless the default IS exact that: empty.

The solution here is a small band aid on one symptom of a much larger issue. And one that we would need to revert once the actual issue is resolved.

That's indeed a well made point.

b_sharpe’s picture

For anyone struggling with fields added post-content, use this, which essentially solves like #34:

https://www.drupal.org/project/field_defaults

dqd’s picture

@b_sharpe: I already placed that project including another link already in a previous comment >> #29

jonathanshaw’s picture

#2769407: Views UI should offer a 'Treat NULL values as FALSE' on boolean field filtering to expose the already existing code path for handling this has sub-system maintainer approval and is more or less RTBC. It should solve the present issue for 90% of use cases. I think this issue should be closed as either won't fix or duplicate.

If this issue is genuinely different from #2769407: Views UI should offer a 'Treat NULL values as FALSE' on boolean field filtering to expose the already existing code path for handling this then the IS should be updated to indicate how it is different.

ressa’s picture

The Field Defaults module is a great interim solution, so thanks for sharing that @diqidoq.

I agree with @Lendude that #1919834: Field instance got no default value when created in field UI is the right solutions for this, since that could prevent a situation where you can't filter a view, since a newly created boolean field by default is NULL for existing nodes, so neither True nor False.

It would be awesome if the features of "Field Defaults" were integrated, so that Drupal core would allow updating values for a new field for existing nodes, but doesn't force it, as @diqidoq mentions in #1919834-41: Field instance got no default value when created in field UI.

jonathanshaw’s picture

Status: Needs work » Closed (duplicate)

Let's call this a duplicate of the mentioned issues unless someone can explain why it's not.

marco.b’s picture

SunnyGambino’s picture

FileSize
5.61 KB

Hi Everyone,
I have a solution for that problem for v9.4. I just thought I share that. :)

--- a/web/core/modules/views/config/schema/views.filter.schema.yml
+++ b/web/core/modules/views/config/schema/views.filter.schema.yml
@@ -7,6 +7,10 @@ views.filter.*:
 views.filter.boolean:
   type: views_filter
   label: 'Boolean'
+  mapping:
+    null_is_false:
+      type: boolean
+      label: 'Evaluate Null as False.'
 
 views_filter_boolean_string:
   type: views_filter
--- a/web/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
+++ b/web/core/modules/views/src/Plugin/views/filter/BooleanOperator.php
@@ -108,8 +108,8 @@ 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'];
+    elseif (isset($this->options['null_is_false'])) {
+      $this->accept_null = (bool) $this->options['null_is_false'];
     }
     $this->valueOptions = NULL;
   }
@@ -149,10 +149,21 @@ protected function defineOptions() {
     $options = parent::defineOptions();
 
     $options['value']['default'] = FALSE;
+    $options['null_is_false']['default'] = FALSE;
 
     return $options;
   }
 
+  public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+    parent::buildOptionsForm($form, $form_state);
+
+    $form['null_is_false'] = [
+      '#type' => 'checkbox',
+      '#title' => $this->t('Evaluate Null as False'),
+      '#default_value' => $this->options['null_is_false'],
+    ];
+  }
+
   protected function valueForm(&$form, FormStateInterface $form_state) {
     if (empty($this->valueOptions)) {
       // Initialize the array of possible values for this filter.
@@ -239,39 +250,87 @@ public function query() {
    *   self::EQUAL.
    */
   protected function queryOpBoolean($field, $query_operator = self::EQUAL) {
+    // Forces a self::EQUAL operator instead of a self::NOT_EQUAL for
+    // performance reasons.
+    $use_equal = !empty($this->definition['use_equal']);
+
     if (empty($this->value)) {
-      if ($this->accept_null) {
-        if ($query_operator === self::EQUAL) {
-          $condition = ($this->query->getConnection()->condition('OR'))
-            ->condition($field, 0, $query_operator)
-            ->isNull($field);
-        }
-        else {
-          $condition = ($this->query->getConnection()->condition('AND'))
-            ->condition($field, 0, $query_operator)
-            ->isNotNull($field);
-        }
-        $this->query->addWhere($this->options['group'], $condition);
+      if (!$use_equal) {
+        $query_operator === self::EQUAL ? $this->queryIsFalse($field) : $this->queryIsNotFalse($field);
       }
       else {
-        $this->query->addWhere($this->options['group'], $field, 0, $query_operator);
+        $query_operator === self::EQUAL ? $this->queryIsFalse($field) : $this->queryIsTrue($field);
       }
     }
     else {
-      if (!empty($this->definition['use_equal'])) {
-        // Forces a self::EQUAL operator instead of a self::NOT_EQUAL for
-        // performance reasons.
-        if ($query_operator === self::EQUAL) {
-          $this->query->addWhere($this->options['group'], $field, 1, self::EQUAL);
-        }
-        else {
-          $this->query->addWhere($this->options['group'], $field, 0, self::EQUAL);
-        }
+      if (!$use_equal) {
+        $query_operator === self::EQUAL ? $this->queryIsTrue($field) : $this->queryIsNotTrue($field);
       }
       else {
-        $this->query->addWhere($this->options['group'], $field, 1, $query_operator);
+        $query_operator === self::EQUAL ? $this->queryIsTrue($field) : $this->queryIsFalse($field);
       }
     }
   }
 
+  /**
+   * Adds a where condition to the query for a boolean being false.
+   *
+   * @param string $field
+   *   The field name to add the where condition for.
+   */
+  protected function queryIsFalse($field) {
+    if ($this->accept_null) {
+      $group_id = $this->query->setWhereGroup($type = 'OR', NULL , $where = 'where');
+      $this->query->addWhere($group_id, $field, '', 'IS NULL');
+      $this->query->addWhere($group_id, $field, 0, self::EQUAL);
+    }
+    else {
+      $this->query->addWhere($this->options['group'], $field, 0, self::EQUAL);
+    }
+  }
+
+  /**
+   * Adds a where condition to the query for a boolean being not false.
+   *
+   * @param string $field
+   *   The field name to add the where condition for.
+   */
+  protected function queryIsNotFalse($field) {
+    if ($this->accept_null) {
+      $condition = $this->query
+        ->condition($field, 0, self::NOT_EQUAL)
+        ->isNotNull($field);
+      $this->query->addWhere($this->options['group'], $condition);
+    }
+    else {
+      $this->query->addWhere($this->options['group'], $field, 0, self::NOT_EQUAL);
+    }
+  }
+  /**
+   * Adds a where condition to the query for a boolean being true.
+   *
+   * @param string $field
+   *   The field name to add the where condition for.
+   */
+  protected function queryIsTrue($field) {
+    $this->query->addWhere($this->options['group'], $field, 1, self::EQUAL);
+  }
+
+  /**
+   * Adds a where condition to the query for a boolean being not true.
+   *
+   * @param string $field
+   *   The field name to add the where condition for.
+   */
+  protected function queryIsNotTrue($field) {
+    if ($this->accept_null) {
+      $condition = $this->query
+        ->condition($field, 1, self::NOT_EQUAL)
+        ->isNull($field);
+      $this->query->addWhere($this->options['group'], $condition);
+    }
+    else {
+      $this->query->addWhere($this->options['group'], $field, 1, self::NOT_EQUAL);
+    }
+  }
 }

iamdroid’s picture

Hi guys, thanks everyone who worked on this.

This is a re roll of #46 against 9.3.

No changes in logic, just removed web/ from file path and added getConnection() to queries where it was missed to make patch applicable. Interdiff doesn't really helpful for this time since path to files are different.

amitajgaonkar’s picture

#47 works for 9.3.

liquidcms’s picture

using #23 with D8.9.20 and it works.

recently upgraded to D9.4.2 and patch from #47 and it no longer fixes this issue.

liquidcms’s picture

My mistake, this works correctly still for 9.4 as long as you use the correct polarity. Use is equal to FALSE rather than is not = to TRUE.

Kakoum’s picture

#47 It works for me. Thanks, it would be nice if it was integrated