I'm not quite sure about this, but apparently the "Is all of" operator doesn't add the condition for matching the field table rows against the base table entity type. To be precise: there's no entity_type=#entity_type# condition in the join.

See: http://karsa.org/views_test/articles3?keys=&field_tags_tid_op=and&field_...

SELECT node.title AS node_title, node.nid AS nid, node.created AS node_created
FROM
{node} node
INNER JOIN {field_data_field_tags} field_data_field_tags_value_0 ON node.nid = field_data_field_tags_value_0.entity_id AND field_data_field_tags_value_0.field_tags_tid = '1'
WHERE (( (node.status = '1') AND (node.type IN  ('article')) AND( (field_data_field_tags_value_0.field_tags_tid = '1') )))
ORDER BY node_created DESC
LIMIT 10 OFFSET 0

I'm pretty sure there should be a field_data_field_tags_value_0.entity_type='node' there somewhere (The "Is one of" operator does add it: http://karsa.org/views_test/articles3?keys=&field_tags_tid_op=or&field_t... ).

The problem with this shows when there are two entities of different types but with the same id. E.g. Article E [nid=5] (which is tagged only with Tag E [tid=5]) shows up when searching for articles with all of Tag A [tid=1] and Tag B [tid=2], because Tag E [tid=5] is tagged with Tag A [tid=1].
I realize cases like this are probably one in a million but it's bothersome nonetheless. :)

Files: 
CommentFileSizeAuthor
#4 exported_view_of_fruit.txt3.54 KBjonraedeke

Comments

Subscribing. Similar issue here using CCK and views filters. User and Node both reference a taxonomy term Source. A view displaying all nodes filtered on type 'article' and 'source' retrieve nodes with the ID of User.

Example Database, field_data_field_source:

(entity_type, bundle, entity_id, field_source_id)
(node, article, 1, 1)
(user, user, 1, 2)

The SQL generated does not filter on entity_type or bundle and will retrieve the Source with tid 2.

Any quick workaround ?

Also got the issue too.

I use same field on node and commerce_product to reference.
In filter got two options, but only affect field options, entitty_type not in the condition.

I get this issue trying to filter file entities by multiple taxonomy terms to make a filtered photo gallery. This is a fairly common use case for D7 and media module.

I would also love to find a workaround.

StatusFileSize
new3.54 KB

The previous comments explain this well, but here are some details and an exported view that show the bug.

Modules:
Drupal 7.23
Ctools 7.x-1.3+4-dev
Views 7.x-3.7+12-dev
File Entity 7.x-2.0-alpha3

Images (file entities with a tags field added):
"Apple"[1] tagged: apple[1]
"Banana"[2] tagged: banana[2]

Articles (node entities):
"Fruit"[1] tagged: apple[1],banana[2]
"Red Delicious"[2] tagged: apple[1],red[3]

from field_revision_field_tags:
entity_type | bundle | entity_id | field_tags_tid
file | image | 1 | 1
file | image | 2 | 2
node | article | 1 | 1
node | article | 1 | 2
node | article | 2 | 1
node | article | 2 | 3

With the attached file view, here are the unexpected results:
Operator | Tags | Result image name
"is all of" | apple,red = "Banana"
"is all of" | apple = "Apple", "Apple", "Banana"
"is all of" | apple,banana = "Apple", "Apple", "Banana"
"is all of" | banana = "Apple", "Banana"

This also seems to be the case for the "is none of" operator:
"is none of" | apple = no result

Here's a workaround that works for my view which is a file entity view with a bunch of exposed taxonomy filters. The filters are set to allow multiple values and use the "is all of" operator.

function my_module_views_query_alter(&$view, &$query) {
    if($view->name == 'my_view') {
      $terms = $query->table_queue;
      foreach($terms as $key=>$term) {
      //find the ones that are multiples by checking for the incremented integer at the end
        if(strpos($key, 'field_data_field') === 0 && is_numeric(substr($key, -1))) {
          $terms[$key]['join']->extra[0]['field'] = 'entity_type';
          $terms[$key]['join']->extra[0]['value'] = 'file';
        }
      }
    }
}

But we don't really need a "workaround", do we? We need a bugfix, this is clearly a bug.