Contrib.social

Allow contextual filters to optionally include results with NULL values for the specified field (as well as matches)

Open on Drupal.org →
Created on 21 April 2021, almost 4 years ago
Updated 1 November 2021, over 3 years ago

Problem/Motivation

Drupal 8 version of a Drupal 7 issue → .

Basically, the use case I have is a multivalued field along the lines of "Intended for users of type X", attached to a node. I want to pass in the user's type as a contextual filter, and have the view return nodes that are intended for that type of user. However, if the content editors did not choose anything for the "Intended for users of type X" field on a particular node, that means it's intended for all types of users on the site, so I want the view to show that node too.

My particular use-case is for news items which may or may not be tagged with a "region code" (the codes are specific to my organisation). Where an item is NOT tagged it's considered "universal", and so we want it to be displayed against all codes. Our contextual filter is populated via a URL path component.

Proposed resolution

Patch incoming which naively adapts the D7 patch in the linked issue. (Works for me, but not robustly tested.)

Remaining tasks


Remove coding standard changes from the patch in #6
Write a Test
Add before and after screenshots to the Issue Summary

User interface changes

Add a mechanism for specifying "matches or is null" on contextual filters

API changes

N/A

Data model changes

Adds storage for a views_argument.include_null boolean value.

Release notes snippet

Adds a mechanism for specifying "matches or is null" on contextual filters

✨ Feature request
Status

Needs work

Version

10.1 ✨

Component
Views  →

Last updated about 13 hours ago

Created by

🇬🇧United Kingdom jrsouth

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

  • Needs screenshots

    The change alters the user interface, so before and after screenshots should be added to document the UI change. Make sure to capture the relevant region only. Use a tool such as Aviary on Windows or Skitch on Mac OS X.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Patch Failed to Apply
  • Comment over 1 year ago →
    🇮🇳India nikhil_110

    Unable to create inter-diff file so inter-diff file was not uploaded.
    Test cases are remaining

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    29,383 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 7.4 & MySQL 8
    last update over 1 year ago
    30,159 pass
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    30,330 pass
  • Comment about 1 year ago →
    🇦🇺Australia sime Melbourne

    The patch works, nice functionality for a few lines of code. This is very useful since you can't work around this limitation with AND/OR groups like you can with filters.

    Should this apply if the validation criteria fails?

    Once we got a few kernel tests this can go to the UX meeting. Would want to see a test on a field that is available via a relationship. Maybe one with aggregation turned on.

    I think this is worth pushing through anyway.

  • Comment about 1 year ago →
    🇦🇺Australia sime Melbourne
  • Comment 8 months ago →
    🇺🇸United States danflanagan8 St. Louis, US

    The patch in #12 worked great for me!

    My use case is that I have a link field on an "alert" content type that indicates which pages the alter should appear on. An alert with no link specified should appear on all pages.

    I attempted to use views_contextual_filters_or → to OR a second contextual filter that returned a default value of NULL, but Views did not seem to want to allow a contextual filter to be NULL. This patch though did exactly what I needed.

  • Comment 7 months ago →
    🇪🇸Spain miguelarber

    The patch in #12 is working for me too, thank you.

    However, there seems to be a situation where the 'include_null' form element is not accessible to the user via the UI (not visible), because its state is depending on the 'glossary' element. There might be use cases where the 'include_null' is required, regardless of the state of the glossary mode (i.e.: in the case of a NumericArgument).

    I have attached a new patch fixing this situation: 3209940-17.patch →

  • Comment 7 months ago →
    🇪🇸Spain miguelarber

    And here is also the interdiff.

  • Comment 7 months ago →
    🇪🇸Spain miguelarber

    Hi again, I'm updating my latest patch as I detected a small typo in the $form['include_null'] item of the NumericArgument views argument. Attached there is the updated patch #19 and the interdiff with #12 and #17.

  • Comment 20 days ago →
    🇩🇪Germany Anybody Porta Westfalica

    Just ran into the same requirement and I agree it would be really useful! If the given field value is empty, it's often a requirement to ignore the contextual filter for the field. Maybe the label of the checkbox could be changed into that direction?

  • Merge request !10923Issue #3209940 by miguelarber, nikhil_110, kapilv, jrsouth, aron novak: Allow... → (Open) created by Anybody
  • Comment 20 days ago →
    🇩🇪Germany Anybody Porta Westfalica

    Great work all! I just created a MR from #19 and can confirm this works great and solves the issue for me.

    Beside implementing tests, I'd really vote to improve the checkbox label a bit for users, because NULL is a bit too technical, I think. We should do that before the usability review, I think.

    What do you think about:

    • Skip this filter for empty (NULL) values
    • Include results with empty (NULL) results for this contextual filter

    What's more clear? Any other suggestions?

    The field description could go more into (technical) ddetail, maybe?

  • Comment 20 days ago →
    🇩🇪Germany Anybody Porta Westfalica
  • Pipeline finished with Failed
    20 days ago
    Total: 1438s
    #397924
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024