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?
Comment | File | Size | Author |
---|---|---|---|
#47 | interdiff_46-47.txt | 11.19 KB | iamdroid |
#47 | boolean-no-value-2862828-47.patch | 5.98 KB | iamdroid |
#46 | patch.patch | 5.61 KB | SunnyGambino |
#23 | interdiff-2862828-21-23.txt | 4.12 KB | tetranz |
#23 | boolean-no-value-2862828-23.patch | 5.87 KB | tetranz |
Comments
Comment #2
cilefen CreditAttribution: cilefen commentedComment #3
cilefen CreditAttribution: cilefen commentedWhen 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.
Comment #4
leovw CreditAttribution: leovw commentedVery true! Yes apologies
Comment #5
leovw CreditAttribution: leovw commentedAnybody looking into this? This is hindering me severely!
Comment #6
mjchadwick@leovw I tried to duplicate this issue the following way:
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!
Comment #7
liorf CreditAttribution: liorf commentedI 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.
Comment #8
LendudeWriting 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.
Comment #9
leovw CreditAttribution: leovw commentedHi - 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
Comment #10
Karol Haltenberger CreditAttribution: Karol Haltenberger commentedI 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:
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 ¯\_(⊙︿⊙)_/¯
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.
Comment #11
Karol Haltenberger CreditAttribution: Karol Haltenberger commentedOn second thought I agree with Lendude.
The newly created field should create the missing field values.
Comment #12
joachim CreditAttribution: joachim as a volunteer commented> 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.
Comment #16
wturrell CreditAttribution: wturrell commentedJust adding my similar issue for exposed filters.
Comment #17
xamount CreditAttribution: xamount as a volunteer commentedI 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
Comment #18
JurgenR CreditAttribution: JurgenR commentedI 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:
Comment #19
tetranz CreditAttribution: tetranz at Third and Grove commentedHere's a patch. Maybe just as a starting point. It adds a checkbox to allow null to be evaluated as false.
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.
Comment #21
tetranz CreditAttribution: tetranz at Third and Grove commentedAdding config schema,
Comment #22
tetranz CreditAttribution: tetranz at Third and Grove commentedI 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.
Comment #23
tetranz CreditAttribution: tetranz at Third and Grove commentedThis 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.
Comment #24
slefevre@ccad.edu CreditAttribution: slefevre@ccad.edu commentedI 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.
Comment #25
tetranz CreditAttribution: tetranz at Third and Grove commentedYes, 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.
Comment #26
LendudeYeah 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.
Comment #27
tetranz CreditAttribution: tetranz at Third and Grove commented@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
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.
Comment #29
dqd@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
Comment #30
jbitdrop CreditAttribution: jbitdrop as a volunteer and at MAROQQO studios commented+1 for #29 - I agree with vote for
Comment #31
dqdPossibly related to my thoughts on this ...
Comment #32
LendudeStill -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.
Comment #33
tea.time CreditAttribution: tea.time commentedHere's a related issue: #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 where people are honing in on a patch to expose the
accept_null
option in the views ui.Comment #34
maskedjellybeanThis 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:
Comment #36
developer-rocha CreditAttribution: developer-rocha commentedSame problem with Drupal 8.8.8
Solved with #23 patch.
Thank you.
Comment #37
markie CreditAttribution: markie at Kanopi Studios commentedMarking as RTBC since I've been using #23 in production for some time and there are other people using it as well. Thanks
Comment #38
alexpottThanks 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:
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.
Comment #39
dqd100% agree on #38 and #32 with 2 thoughts added. @Lendude thanks for your thougths on it.
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.
That's indeed a well made point.
Comment #40
b_sharpe CreditAttribution: b_sharpe at ImageX commentedFor anyone struggling with fields added post-content, use this, which essentially solves like #34:
https://www.drupal.org/project/field_defaults
Comment #41
dqd@b_sharpe: I already placed that project including another link already in a previous comment >> #29
Comment #42
jonathanshaw#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.
Comment #43
ressa CreditAttribution: ressa at Ardea commentedThe 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 neitherTrue
norFalse
.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.
Comment #44
jonathanshawLet's call this a duplicate of the mentioned issues unless someone can explain why it's not.
Comment #45
marco.b CreditAttribution: marco.b as a volunteer commentedComment #46
SunnyGambino CreditAttribution: SunnyGambino as a volunteer commentedHi Everyone,
I have a solution for that problem for v9.4. I just thought I share that. :)
Comment #47
iamdroid CreditAttribution: iamdroid at SystemSeed commentedHi 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 addedgetConnection()
to queries where it was missed to make patch applicable. Interdiff doesn't really helpful for this time since path to files are different.Comment #48
amitajgaonkar CreditAttribution: amitajgaonkar commented#47 works for 9.3.
Comment #49
liquidcms CreditAttribution: liquidcms commentedusing #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.
Comment #50
liquidcms CreditAttribution: liquidcms commentedMy 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.
Comment #51
Kakoum CreditAttribution: Kakoum commented#47 It works for me. Thanks, it would be nice if it was integrated