Problem/Motivation

Exposed filters currently have a "Limit list to selected items" option, which is fantastic when you have a definite set that that won't change. But if you have an indeterminate or volatile set, you may want to exclude certain items instead. For example, I have an exposed author (user) filter on a table of nodes. I don't want to include the Anonymous user, since only authenticated users can create content in my system; and I don't want to make my root user (Uid 1) username discoverable via autocomplete. I can't hardcode the options, because I may add or remove users over time. What I really want to do is just exclude Anonymous and WhateverMyRootUsernameIs. Does that seem like a feature worth adding? If not, perhaps someone could suggest achieving the functionality in a custom module. Thanks! :)

Steps to reproduce

Proposed resolution

Remaining tasks

Tagged for subsystem maintainer review to determine if this is working as designed per #17.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

lendude’s picture

Project: Views (for Drupal 7) » Drupal core
Version: 8.x-3.x-dev » 8.1.x-dev
Component: exposed filters » views.module
Issue summary: View changes

Moving to the right issue queue.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.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.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.

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

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

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

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

johnv’s picture

Category: Feature request » Support request
Status: Active » Closed (works as designed)

Yes, you can do this.
Just add an additional non-exposed filter and select 'Is not one of' 'Anonymous'.
(Indeed, the exposed filter might still expose the irrelevant user roles).

I guess this very old issue can be closed.

mibfire’s picture

Version: 11.x-dev » 10.6.x-dev
StatusFileSize
new2.38 KB

@johnv

No, what you suggested is not a solution. That is just a half solution. So this ticket shouldn't be closed until this is fixed. I fixed this in a patch that i attached, but to be honest i don't really like how the views works with exposed filter and "Limit list to selected items" checkbox. I mean
because if you have an exposed filter and you select options there this doesn't do anything. This works only if you tick the "Limit list to selected items" checkbox, and this doesn't make any sense. If i select something in the options i would expect to see only these options in the select list. Or this should be other way around when i enable "Limit list to selected items" checkbox then i should see the list that i can select options from.

Either way now I aligned this extra logic to the current one, and there won't be any backward compatibility issue either. But as i said the whole logic should be fixed how the views works now with exposed filter.

mibfire’s picture

Status: Closed (works as designed) » Active

I reopened the issue.

quietone’s picture

Version: 10.6.x-dev » 11.x-dev
Category: Support request » Feature request
Issue summary: View changes
Issue tags: +Needs subsystem maintainer review

As far as I can tell the comment in #17 answers this question from the issue summary about how to accomplish the desired filtering. It is not clear to my why that is not sufficient.

So, restoring the feature request category. Also, changes are made on the main development branch, 11.x, so changing version.Also tagging for subsystem maintainer review to determine if this is working by design.

mibfire’s picture

@quietone

@johnv also mentioned why that solution is not sufficient.

(Indeed, the exposed filter might still expose the irrelevant user roles).

So there will be options in the select list that shouldn't be there.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.