Problem/Motivation
Using 'Is not equal to' in a grouped exposed filter for a boolean field does not work as expected.
Steps to reproduce
- Install Drupal
- Create a content type with a boolean field
- Create a node with the boolean field checked
- Create a node without it checked
- Create a view of this node type
- Add an exposed, grouped filter where
- Grouping 1 = Label: True, Operator: Is equal to, Value: True
- Grouping 2 = Label, Not true, Operator: Is not equal to: True
- Test the exposed filter, see that the node with the field checked appears for both True and Not true
Expected result: The node without the field checked should appear for Not true
The SQL query for both filters is the same:
SELECT "node_field_data"."langcode" AS "node_field_data_langcode", "node_field_data"."nid" AS "nid"
FROM
{node_field_data} "node_field_data"
LEFT JOIN {node__field_checkbox_1} "node__field_checkbox_1" ON node_field_data.nid = node__field_checkbox_1.entity_id AND node__field_checkbox_1.deleted = '0'
WHERE ("node_field_data"."type" IN ('checkbox')) AND ("node__field_checkbox_1"."field_checkbox_1_value" = '1')
LIMIT 11 OFFSET 0Proposed resolution
Allow boolean fields to be used with grouped filters for 'Is not true'.
Remaining tasks
- Write patch with tests
- Review
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
==================
Problem/Motivation
In a view, for an exposed, grouped filter, the specified operator is apparently ignored.
Steps to reproduce:
- a clean install of 8.7.6
- in /admin/structure/views/settings, turn on Show the SQL query (you need to tick 'Show information and statistics about the view during live preview' first, which is a bit of a UX issue in it's own right, imho)
- then edit the Content view (views.view.content)
- edit the Content: Published filter (labelled 'Published status')
- change the second grouping (Unpublished) from: 'is equal to no' to: 'is not equal to yes'
- test each value of the dropdown using the Preview, examining at the SQL query
Expected:
selecting Unpublished and pressing Filter should give a query fragment of:
WHERE (node_field_data.status != '1') AND …
Observed:
WHERE (node_field_data.status = '1') AND …
(similarly, if you set it to 'is not equal to no', you still get: node_field_data.status = '0')
Proposed resolution
Remaining tasks
- Is this a duplicate of another bug? (I did a cursory search)
- Establish cause.
- Write patch.
User interface changes
none
API changes
none expected
Data model changes
none expected
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 3073518-19.patch | 11.24 KB | mohit_aghera |
| #11 | views-grouped-exposed-filter-operator-ignored-3073518-11.patch | 1.76 KB | eugene bocharov |
| #6 | unpublished_result_after_apply_patch.png | 27.34 KB | rensingh99 |
| #6 | unpublished_result_before_apply_patch.png | 38.07 KB | rensingh99 |
| #6 | filter_change.png | 21.18 KB | rensingh99 |
Comments
Comment #2
wturrell commentedUploading the modified configuration of the view.
(I'm half expecting this to be a duplicate - but the only issue I turned up so far was:
#2595169: Operator 'Is not equal' of BooleanOperator doesn't work)
Comment #3
wturrell commentedActually it appears I reported it once myself last year, but nobody commented on it: #3014579: 'Is not equal to' operator does not work as expected for boolean field in grouped exposed filter
Comment #4
rkostov commentedThis patch should work.
Comment #5
rkostov commentedComment #6
rensingh99 commentedHi,
I have edited the "Content: Published (grouped)" filter from: "is equal to no" to: "is not equal to yes" in the "Content (Content)" view. Below is a screenshot.
Before applying the patch
Screenshot output of view with status filter "Unpublished".
After applying the patch
Screenshot output of view with status filter "Unpublished".
The patch is working as designed.
Thanks,
Ren
Comment #10
agileadamYES! Thank you for this patch.
Without it (on 9.1.3), my exposed grouped filters for select list fields were not working properly. Here's what was happening:
All of those work as expected after patching.
Comment #11
eugene bocharov commentedThis is the patch for 9.2.x. Also applicable to 8.9.x.
Uses exactly same logic as in #4. I just made some changes to improve readability of related code block. The originsl problem was that exposed group filter store operator id in the key $this->options['expose']['operator'] , but at the next step exposed filter read it from $this->options['expose']['operator_id']. As result any filter from exposed grouped filter had used operator from single exposed filter insted of its own.
Comment #16
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
Did not test for issue FYI
But this will need a test case to show the issue and that the fix address it.
Thanks!
Comment #18
quietone commentedI tested this on Drupal 10.1.x and was able to reproduce the problem.
This is a duplicate of the earlier issue, but let's keep this one as it has more discussion and a patch. I have copied the Issue Summary from that issue because pameeela did a great job of summarizing the issue. This still needs tests.
Comment #19
mohit_aghera commentedAdding a test case and test only patch.
Note regarding new test-view added:
I tried to modify existing views by adding filter programmatically similar to `FilterBooleanOperatorStringTest`
However, it was not working as expected. I tried with different views from node_test_views module's test views.
It didn't work as expected.
So at last, I ended up creating seperate view for testing purposes.
Comment #20
mohit_aghera commentedComment #22
mohit_aghera commentedComment #23
smustgrave commentedTested following the issue summary steps and confirmed the issue.
Patch #19 addressed it for me.
Red/green shows good test coverage.
Good job @mohit_aghera with the tests!
Comment #27
catchCommitted/pushed to 10.1.x, cherry-picked to 10.0.x and 9.5.x, thanks!
Comment #29
pameeela commented