Entity Reference works great so far. I replaced my field that had used the References module with an Entity Reference field. I was easily able to replace any contextual filters with the new field. The only problem is that I can't replace my exposed filter that the References module allowed.

I have a client content type and a project content type. Within the project content type is a select list called Client which is now an Entity Reference field instead of a Node Reference field. On the projects view (page view) I need an exposed filter that will be a select list so the user can filter projects by client. The way I had it setup through the References module allowed it so the user could select a client from the select list and then only that client's projects would be displayed on the page.

It seems that under Filter criteria I can only select (target id) or (target type) for my Entity Reference field which are both text fields that take values.

If this functionality is not available yet for the Entity References module that is fine. I just wanted to make sure there isn't something that I'm missing or if there is any other solutions or add-ons to make this happen. I am trying to do away with References module completely but I can't unless I figure something out for this.

Files: 
CommentFileSizeAuthor
#25 1392702-behavior-views-filter-select-25.patch2.42 KBAmitaibu
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#20 1392702-behavior-views-filter-select.patch2.38 KBDamien Tournoud
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#19 1392702-2.entityreference.views-filter-options.patch1.3 KBjoachim
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#17 1392702.entityreference.views-filter-options.patch836 bytesjoachim
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

Comments

Need it too :)

I'm also stuck with this and think it's not yet been implemented. A confirmation would be good though.

Status:Active» Closed (duplicate)

This looks like a duplicate issue to me: http://drupal.org/node/1253776

Status:Closed (duplicate)» Active

These issues are not related

Haven't found a solution either but I'm very interested too.

Title:Is there any possible way to use the entity reference field as an exposed filter select list in views?Entity Reference does not offer select list as a views exposed filter, only text field for id number
Component:Miscellaneous» Code
Category:task» bug

There are a couple things in the current views implementation that are a little strange. I'll take a stab at this as I need this too and see if I can scrape from references what we need.

I second #4 posted by webankit - this issue does not relate to the linked issue.

A workaround I have though about, is to use taxonomy as the content type. As a fieldable entity, it can have fields. Exposed filter then is supported using all kinds of widgets. Does anyone can see any drawback to this?

Thanks,
Amir

@Amir Simantov I see a few drawbacks to this.
1) Taxonomy requires a description field, not all entities are taxonomy.
2) Taxonomy is and entity, an entity is not taxonomy. If we go that route then we are back to everything is a node mentality which didn't work out so well.
3) We don't need the overhead of the taxonomy system when all we needs is entities.

Why should taxonomy get all of the goodness of exposed filters and all other referenced entities not take advantage of it.

When I was thinking about this in the shower it hit me where I saw this behaviour before, it was taxonomy. Why don't we try to port the taxonomy filters to entity reference so we get that goodness here too.

and yes to #4 these issues are completely unrelated. One is a field that gets it's data from views, this is creating filters in views for views. However on my wishlist would be to be able to use a view as a filter so that you could limit the available options for the filter and use different fields for the value of the select list as title tends to not be unique.

Thanks haydeniv, i see your points.

Why don't we try to port the taxonomy filters to entity reference so we get that goodness here too.

Isn't it better to generelaized the taxonomy filters to entity filters? Is it possible?

@Amir I talked to merlinofchaos last night and he did not sound optimistic about what we are trying to accomplish. He said that the taxonomy filter was one of the least favorite experiences he had creating views and taxonomy is more consistently structured than entities. Here are a few things so far that I have found that will need to change to make this happen.
Modules:
entityreference
entity (api)
views
and possible Drupal core

We need to determine a way to generate unique entity titles. What happens if two entities have the same title when you use auto complete. Most likely this will be accomplished by using a second or third field from an entity to create the search list (list of titles to choose from). Some of this may get figured out by Add views support for providing a list of entities or bundles (views filtering, relationships, etc). Still that could get tricky trying to get views to let us filter on a view that may or may not exist yet.

Either way, taxonomy is currently hard coded into the views module and I don't believe the api is very good yet in the views filter world for doing something like this. I could be wrong though I have not dug too far into views yet.

I see entity (api) need to expose a few more things as well to make this happen although I have not figured out just what yet.

At the end of the day I think we are going to need to get this issue some visibility from each of those module maintainers to get this done.

A workaround suggestion for the OP:

<?php
function modulename_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {
  if (isset(
$form['field_client_target_id'])) {
   
$form['field_client_target_id'] = array(
     
'#type' => 'select',
     
'#options' => modulename_get_clients(), // get array of 'client id' => 'client label'
     
'#default_value' => $form['field_client_target_id']['#default_value'],
    );
  }
}
?>

Adjust to module and scope of field to replace.
Not perfect, but it may hold the tide until we get something solid built-in.

I'd love to see this.

Could the following module be a source for code ideas? http://drupal.org/project/entityreference_view_widget

To be honest I don't know exactly what that project is trying to accomplish but if it's what is being talked about here, I think they're rather nuts to develop a separate module just for this functionality.

@nodecode

entityreference_view_widget is a separate way of choosing entities on the edit form. It is an alternate approach to #1253776: Add views support for providing a list of entities or bundles (views filtering, relationships, etc) which lets you use a view as a select list or autocomplete field data source for the entity reference. This issue is about using an entity reference field as an exposed filter of a view. Views filters allow to you limit the data that is displayed on a view.

@haydeniv
Thanks for investigating it further down; it looks like it will not be implemented before d8. We will have to find other solutions.

@JvE
What should the modulename_get_clients() function return? And can it be with autocomplete, instead?

I do not care for multiple items having the same title.

Thanks.

@Amir:
For #select #options you need an array with client entity ids as keys and client entity labels as values.
How you get these is not really in the scope of this issue.

I suppose you could get this use-case specific custom workaround to work with autocomplete using a #textfield with #autocomplete_path entityreference/autocomplete/single/client_target_id/node/client

This really shouldn't be rocket science; it's just a question of providing a custom filter handler for the Views filter.

All it has to do is find out which entity type and bundle(s) can be referred to by the field in question, and do a query to get those titles. That's entirely analogous to how the taxonomy filter loads all the terms for the vocabulary the field uses.

(merlinofchaos's horror stories about taxonomy support in Views are probably to do with supporting hierarchies and all that stuff which we don't need to worry about.)

EDIT: in fact might not even need a custom class; views_handler_filter_in_operator lets you define an 'options callback' in its views data definition.

Version:7.x-1.0-beta3» 7.x-1.x-dev
Status:Active» Needs review
StatusFileSize
new836 bytes
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

Twenty minute patch :D

Turns out we didn't even need a callback, there's one already in the module.

(Though adding a wrapper around entityreference_options_list() so we store just the field name rather than the whole field array in views data might be a nice touch maybe?)

StatusFileSize
new1.3 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

Here's an updated version with that improvement.

StatusFileSize
new2.38 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

I re-implemented the same idea as a behavior. This cannot be the default, because it will not scale as soon as the number of referencable entities is too large.

@Damien Tournoud How many referencable entities is too large?

@haydeniv: a couple of hundred would already be too much to render as a select field. I would recommend less then 50.

Category:bug» feature

@Damz,
EDIT: I couldn't apply your patch -- is it a full patch or an interdiff?
Minor: The plugin definition should be inside a module_exists('views');

StatusFileSize
new2.42 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

Attached patch just adds module_exists() on plugin definition, and a description, so it would be clear when to enable/ disable behavior.

Status:Needs review» Needs work

+++ b/plugins/behavior/views-select-list.inc
@@ -0,0 +1,10 @@
+    'description' => t('When enabled Views filters of this field, will have a select list, instead of a text field. This should not be used when there are over 100 entities, as it might cause an out of memory error.'),

Way too many commas in that ;)

'When enabled, Views filters of this field will have a select list instead of a text field.' is how it should be.

Though I tend to think that phrases like 'when enabled' add no meaning at all and are just noise. So:

'Provides a select list for Views filters on this field.'

I tried patch #25 and it works. Thanks!
However I had to clear the Views cache, before the selectlist of operands appeared in the View's filter form.

Status:Needs work» Fixed

Merged in 7.x-1.x.

Has this been committed to dev or beta-5?

I've tried both versions, cleared my caches, and I still can't figure out how to make this work. There simply is no option for a select list. Could somebody provide a step-by-step or a screenshot showing how to make this work for an existing view? Thanks.

I'm having the same problem as in #29. I'm using a view with an entity reference relationship between two custom content types and can't find any options for using a select list. I only get the option for a blank text field. If I use a relationship to the user then I am getting an autocomplete box.

I'm using 7.x-1.0-beta5. I've checked the files and the files I have seem to be the updated code with the select list function.

Any help would be much appreciated.

You may want to revisit the Manage fields page, and tick a new option:

Enable Render Views filters as select list

at the end of the field edit page:
admin/structure/types/manage/TYPE/fields/field_NAME

Thank you gausarts for your help. Coincidentally, I just stumbled upon it. However, when I enable the render views filter as select list I then get an error when I try and add an exposed filter based on that field to my view, and the view won't save. The error I get is "The operator is invalid on filter: Content: Assignment" (Assignment is my field). I've tried deleting the filter and adding it again but still having the same error. When I disable the render views filter as select list option the filter works fine.

Here's my work around for this (D7 but I've done something similar in 6 too):

I have a list of users that have an entity reference field. I created a page view using an entity reference as the contextual argument that lists the users.

Then I created a block with the nid and title of the content type that is being referenced. Each title links to the page view of the users with the nid as the argument. The block displays on the page view.

It's not real filtering but it allows for similar functionality.

Thanks kayelle, that sounds like a good alternative.

#32
I have the same problem.
Error occurs even if the field is not used in filter.
All that I have found is that validate() function in views_handler_filter_in_operator get defailt operator method "=" instead of "in" ( $this->operator).

Entitity referenced field is used in Field collection.

Creating a new views display solved my problem (#35).

Status:Fixed» Active

I think it would be nice to also have an autocomplete widget.

Status:Active» Fixed

Please open a new feature request.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

I am not seeing a select list when using it in the Views Filter Criteria section.

Basically the only option I am getting is auto complete.

Status:Closed (fixed)» Needs review

changed to Needs Review

Has the patch in #25 been committed yet ?

Status:Needs review» Closed (fixed)

@kclarkson
Have you tried checking the box mentioned in Comment #31

gausarts, you're the man!

Along with the last couple of comments on this issue I'm having trouble getting this actually working. New issue filed at #1778368: Views filter as select list does not work due to "The operator is invalid on filter".

@Dave Reid see #1778368: Views filter as select list does not work due to "The operator is invalid on filter" for an answer to the problem even though it probably needs some love to update any views that are using the field before the check box is checked.

hii..

i used your idea and it really worked. But it gives 'An illegal choice has been detected. Please contact the site administrator.' error while loading the page for 1st time. But when i select the option and Apply then it doesn't give any error. Can you guide me here please?

Ananya - This may be because you have "Select all" as one of the check options when configuring the field in the views filter criteria.

This enhancement is a little buggy. If you check "Select all", the view results in an error on initial display as you have identified. If you leave all options unchecked, the views administration complains that "No valid values found on filter [...]". We shouldn't have to check records in the options list since the list is almost always going to be dynamically changing.

To make this scalable we could have an autocopmlete widget as well like this one http://drupal.org/project/term_ref_autocomplete

Doesn't seem to work with Search API.

By enabling 'Render Views filters as select list' at Manage fields >> field (Entity Reference) >> edit, I get

Notice: Undefined index: field_***_target_id in views_handler_filter->accept_exposed_input() (line 1260 of /***/sites/all/modules/views/handlers/views_handler_filter.inc).

And by disabling 'Render Views filters as select list' at Manage fields, I get a text field as exposed filter which can only search by ID as mentioned in the very beginning of this thread.

Edit: Got the exposed filter work now after reading linked thread #44

I also had the problem with Search API. Check out this issue for a patch: #1980450: Entity Property info is missing an 'options list' callback

#33 is a good workaround. Here is another recipe that uses a similar technique with the Jump menu display type, which results in a very functional select-list filter:

  1. Add a contextual filter to your page view that filters based on entity ID.
  2. Create a separate view with a jump menu display which pulls up the entities that you want to filter on. Use rewrite field results to construct a URL for the jump menu using the URL of your page view + the entity ID of each row. Use other field(s) for the label of each option in the jump menu.
  3. Back on your page view, insert your jump menu view into the header as Global:View area. Tick the box for "inherit contextual filter values" (this will make your jump menu focus on the particular entity that is controlling filtering on the page view).

Now you have a nice filter at the top of your page view that is highly configurable in terms of the labels for each option in the list!

#52 is genious !!
First time I use jump menus, thank you for that explanation !

Sure thing Woodyjon, I came up with it because I needed what this issue was asking for. I find it quite useful

as I filter criteria in view I can see all strings as "Array" instead of the Node Title.

v Select all
v Array
v Array
v Array
v ...and so on
Am I missing something here?

Thanks gausarts (#31)! Just the answer I was looking for!

You can use Entityreference Views Filter to generate a list of referenced entities that can be exposed to the user. With Better Exposed Filters you can select to display the results as select-lists, links or radio-buttons/check-boxes. This way you can use a block display without any workaround.