Boolean default values are not saved

The only value that seem to have a problem are boolean filters. Other filters that I tested seemed to work fine.

For the boolean values there are a couple of different things happening:
- Yes (value 1) works
- No (value 0) doesn't work. It's not saved but does shows up selected after clicking Apply and then opening the filter edit screen again. Opening the filter edit screen after save shows no selected radios.
- - Any - (value All) doesn't work but this gets interesting! When you select -Any- and apply and then open the filter settings again 'No' is selected (because of #1381140: A #default_value = 0 for #type radios checks all radios), and if you select -Any- apply this and save the view and then open the filter settings 'Yes' is selected! (I'm assuming this is because the value 'all' gets cast to 1 on save).

I'm experiencing this too. Moving to 8.2.x.

This is a bug fix so it can stay in 8.1.x for now.

Some of the findings we got in #2369119: Fatal error when trying to save a View with grouped filters using other than string values about this.

The problem seems to be that the exposed boolean filter value cannot be stored in a boolean field, this is because it can have 3 values (yes-no-all). The non-exposed boolean filter value only has 2 values, so that's fine.

Currently there is no way to use a different format for the exposed filter value then for the non-exposed filter value.

Two things I can think of to solve this:
1-Make it possible to set a different storage format in config for the exposed and non-exposed values.
2-Make the boolean filter alway store the filter value as a string

any other solutions?

Hi,

I am looking into this. I am able to reproduce it on my local setup.

@lendude : it seems to be the different issue, as the filters present on the exposed form is having 3 values while at the view preview page its showing 2 values. I think while making the filter exposed its forming 2 values instead of 3. is it the correct understanding?

@lendude : my bad, i think its could solve the issue as suggested by you i will try to modify the scripts and let you know about this.

Changing status.

#2734197: FilterPluginBase::acceptExposedInput should check 'All' strictly has been postponed on this as @Lendude thinks this is the root cause, though from my testing I am not sure that is the case.

dhrjgpt2005, did you mean this one?

Hi Kalistos,

Thanks for the perfect patch.
Need to run this patch with 8.1 and 8.2 also needs to update some of the test cases.

I will be doing the fixes for the test cases soon.

Is there any workaround for the moment ? If I do a form alter on views_exposed_form and set the default value to 'All', the default value still jumps to the first option (true). Tried setting it to to '- Any -' as well.

Thanks for taking a look at this @dhrjgpt2005 but not sure if #23 is the way to go.

Here is my first stab at a fix. This converts the values for boolean filters to strings.

Couple of things:

• I probably missed converting some Views, but lets see how far I got.
• The test-only patch will pass, but that is only because of #1381140: A #default_value = 0 for #type radios checks all radios, with the latest patch (#69) applied, this fails as expected.
• The update might need tests too?

This should clear up some fails.

Lets see if I got them all. Passes locally now.

@lendude thanks for looking into this. I will verify this at my end too.

@lendude: i tried to run the patch on 5.6 and it gets failed on 2 locations, so do we need to look into that as well.

I would have expected that the boolean filter itself would have to be changed, now that we are using strings, instead of booleans. This might be a reason for the failure in 5.6?

1. +++ b/core/modules/views/views.install
   @@ -390,5 +390,39 @@ function views_update_8101() {
   + * Set all boolean filter values to strings.
   + */
   +function views_update_8102() {
   

   Is there a reason we cannot use a post update here?

2. +++ b/core/modules/views/views.install
   @@ -390,5 +390,39 @@ function views_update_8101() {
   +            $new_value = FALSE;
   +            // Update all boolean values to strings, ignore other values.
   +            if ($filter['value'] === TRUE) {
   +              $new_value = '1';
   +            }
   +            elseif ($filter['value'] === FALSE) {
   +              $new_value = '0';
   +            }
   

   There might be instances with 1/0 out there, should we take into account them as well?

I would have expected that the boolean filter itself would have to be changed

So would I, but the code that distinguishes between on and off in \Drupal\views\Plugin\views\filter\BooleanOperator::queryOpBoolean is if (empty($this->value)) {, so it doesn't matter is you give it FALSE, 0 or "0", it's all empty. It just works.

37.1 Only reason was that I had no idea that existed, fixed.
37.2 Updated, it would be a bit weird to run into that because that would violate the current schema too, but who knows what's floating around out there.

Wrote a update test, but can't get it to pass locally, keeps timing out, so its completely untested so I don't have high hopes for it yet.

No idea yet why it fails on 5.6.

This is probably to invasive to target 8.1.x, so moving to 8.2.x

lets see what this fixes.

Update test passes locally now and some more views got added.

Moved the upgrade test view to fixtures folder so it won't cause a fail of TestViewsTest (since the whole point of the view is that it starts invalid). Other option would be to change TestViewsTest to allow a view to be ignored.

This patch will fail every time a new (test)view is committed that uses the status filter.

The failing test was because \Drupal\system\Tests\Update\UpdatePathTestBase::runUpdates assumes that the config is up-to-date even when you have (and expected) failing updates. This seems strange to me, so I moved the config check into the if ($this->checkFailedUpdates) so you only expect an up-to-date config when you expect no failing tests.

The failing test was because \Drupal\system\Tests\Update\UpdatePathTestBase::runUpdates assumes that the config is up-to-date even when you have (and expected) failing updates. This seems strange to me, so I moved the config check into the if ($this->checkFailedUpdates) so you only expect an up-to-date config when you expect no failing tests.

That is totally logical

A new test view got committed so this was failing again.

Updated the new view.

This is going to be the reroll patch from hell :)

A new test view got committed so this was failing again.

That is always a good thing

Unrelated fails, the fail on php 5.6 looks unrelated too.

What happens if a contrib module provides a view as default config using this filter? I see the test fails above with test views, but not clear if that translates to an actual user-facing/config install issue with an exported view.

This is not a concern here, because we don't change any runtime code. If something magically managed to save the right value, for example by manual changing things, they continue to work.

Makes sense. Committed/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!

8.1 reroll for those who're interested, credit to @welly