When using operator "Is one of" and "Limit list to selected items" - 'Any' should not ignore the selected items.

Please don't push issues like this, people work hard to the queue so everything below 2 weeks is fast. If you think no, have a look at the amount of issues :)

So you created an issue in the views issue queue so you saw http://drupal.org/node/571990 didn't you?
Please for example describe what kind of filter behaves like this... therefore an export of the view would have answered it automatically.

Another question is whether you have selected "optional" or not.

Well sure this feature absolute makes sense and is sometimes what you want but often people expect another behaviour, so technical it's a new feature.

It's somehow hard to think what's the best way to bring this into views in a general way, perhaps you could write some custom code here to solve it first for you own. You are welcomed to make a generalized addition to views.

In this issue, I agree with thomas1977.

I have an exposed filter of content types. I limit the list to selected ones. But there is -any- option and by default, this view shows all the content types, which is unwanted. Using the latest Views version...

I've switched this back to bug report instead of feature request because the requested feature does already exist in the code -- it's just not working properly because of a typo.

In my tests, the attached patch fixes the issue. The '-Any-' option still appears in the list, but selecting it displays only items that match the selection specified in '"Limit list to selected item".

The source of the problem is that one line of code in views_handler_filter_in_operator.inc refers to a nonexistent option, 'limit'. However, the correct machine name for the "Limit list to selected item" option is 'reduce'.

This seems like a clear bug and the patch looks correct... however, it could be a bug that morphed into a feature at some point?

In other words, the current help text on the "Limit list to selected items" (which says "If checked, the only items presented to the user will be the ones selected here") is not 100% clear that it's also supposed to modify the behavior of the "Any" option. Personally I do interpret it that way, but this patch will change the behavior of views in a way some people might not be expecting.

Would another solution be to add a separate checkbox on the configuration form for this specific purpose, and have the code check that rather than $this->options['expose']['reduce']?

This patch also mainly makes sense if the filter operator is "Is one of". If it's set to "Is not one of" then things get... confusing. Because then the "Any" option in the exposed filter goes from actually meaning "Any" to instead meaning something like "Anything that is not one of the other options in the dropdown".

this worked for me according to what is outlined in introduction.

worked with user views also..

Pathch #9 works for me for content type exposed filter. Thanx Nephele.

But it doesn't work for exposed term reference field filter. The list is not reduced to selected referenced terms but it displays content referencing all terms from vocabulary as described in #5.

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

Per request, I'm re-uploading the patch

#10, #11, and #14 should be addressed before we commit this.

I have added an additional condition on term node filter, because it was ignoring the reduce when the filter is not required.

Patch reviewed... in some views limit is not declared and raise an error. Condition updated to avoid such error.

git apply views-use_reduce_option_when_any_selected-1309578-19.patch
fatal: corrupt patch at line 26

Looks like an error on EOF char... can you try to apply it manually only for testing purpose?

I've applied it manually and works like a charm!

this check on 'limit'
&& !empty($this->operator['limit']) && !$this->operator['limit']
is self-contradicting, isn't it? any value that resolves to FALSE will cause empty() to return TRUE.

if the idea is to make sure that limit is not set to some non-empty value, i think you could just do
&& empty($this->operator['limit'])

i'm not sure i understand the purpose of adding that test there, though. since the line before the patch didn't reference $this->operator['limit'], how could it have been causing an error if it wasn't set? i see, this was compared to patch 18 not 9. so i think this reroll matches the original intent of patch 18.

@brad.bulger, I included the double check because I found a case in which $this->operator['limit'] was not defined and an error was raised. You could replace it by array_key_exists.

And yes, you can replace
&& !empty($this->operator['limit']) && !$this->operator['limit']

for
&& empty($this->operator['limit'])

From my point of view, you will get a better performance, but a sentence harder to understand for maintenance.

but those are not equivalent. the first one will never test TRUE, its first half contradicts its second half. there is no value such that !empty(value) and !value are both true.

if what you want to do is only bail when the field is not required and has no value and there is no limit, then empty($this->operator['limit']) will work whether operator['limit'] is defined or not.

There is one difference. You are assuming that when limit is not set is equivalent to set it to FALSE. I don't remember the exact case and I should search for it, but in here I'm assuming that "not set" is equivalent to TRUE.

So, the condition is solved only when the "limit" is set and its value is FALSE. And it is not solved if "limit" is not set or if "limit" is set to TRUE.

that's not how it works. empty($array['index']) returns TRUE if the key "index" does not exist in $array.

if you only want to bail when $this->operator['limit'] does exist and has a false-ish value, it depends on if you want to include NULL. if you do, you'd have to use array_key_exists() and then !. if not, you can just use isset() and !.

if it is ok to bail when $this->operator['limit'] either doesn't exist or is false-ish, then you can just use empty()

probably details about some actual cases where this matters would help to clarify things.

Some other way of writing the same logic (I add all the explicit checks):

isset($this->operator['limit']) && !is_null($this->operator['limit']) && $this->operator['limit']===FALSE

that could be simplified as (!is_null($this->operator['limit']) is already tested on left and right):
isset($this->operator['limit']) && $this->operator['limit']===FALSE

So, in that case we want "not set", value "null" and value "TRUE" are equivalent. Only explicit value "FALSE" accomplish the condition.

In a new website I'm using #19 with Views 3.18 + Drupal 7.57 and works as I expected

Deleted comment... as not relevant any more.

This is my personal opinion: I don't see this as a bug because when we say "any" that's mean any node item and "Limit list to selected items" means filter out un-selected items from the list (not actual result/node item). If we want future filter it down to only display certain node item/taxonomy item then we can add another hidden filter with restriction.

It worked for me.

We can add this in documentation (if already not available). I personally not fill to make any code changes but leave this decision on Module maintainer.

Re: #31

I agree. Very similar D8 issue created few days ago is Closed (works as designed) - with detailed explanation why. So, I suppose we can close this D7 issue as well.

However, due to not so precise use of words in "Limit list to selected items" checkbox title and description for all D7/D8/D9 drupalers who will come for the first time to this checkbox in the future - there will always be two ways how they can understand the checkbox functionality.

So, I have started an initiative to alter checkbox title and description in order to make their meaning more precise and to avoid any further misunderstandings about "Limit list to selected items" checkbox proper use.

Please, feel free to join D9 Support Request: #3133906: "Limit list to selected items" checkbox - Title and description adjusting