Real name changes the entity reference behavior with views

First bad commit:
http://drupalcode.org/project/realname.git/commit/2ec306b78b49474a28efbf...

Previous patch is broken autocomplete.

The enityreference patch was very long in issue queue and fixed several issues for my users. You have not helped reviewing it and It was as not a bad commit. It made entityreference useable with realname.

This issue could be a duplicate of #1239478: How to display a user's username (not real name) in Views once RealName is enabled?

I think part of the issue here is that we're not altering the query in buildEntityFieldQuery for the EntityReference autocomplete class handler.

If we implement a hook_query_alter on this tag, that might fix the query side of this issue. Similar problem in commons reported here: #1965862: Entityreference autocomplete for users still searches by username but displays full name instead

#1965862: Entityreference autocomplete for users still searches by username but displays full name instead sounds 100% like the bug I fixed in realname v1.2 with issue #1722112: Autocomplete for entityreference fields

Patch from #2 seems to partially resolve the problem, but what append if it's not a "view" plugin but a "my_custom" plugin ??

I don't know if it's a good solution, but I made a little patch to add plugin checkboxes on realname administration to disable realname autocomplete application on specific handler plugins.

I have the same issue as Dhamub.
In my opinion, real name should not override the #autocomplete_path when the entityreference field is set with a view (all the more so as the real name can be displayed using the view fields).

I suggest to replace realname.module line 409:
if ($context['field']['settings']['target_type'] == 'user') {
to
if ($context['field']['settings']['target_type'] == 'user' && $context['field']['settings']['handler'] != 'views') {

Could you please commit this change to dev if you think it is appropriate? Thank you in advance.

Up

#9 has been working fine for me so far. Is there any drawback to implementing it in the dev version?

There is no patch to review.

Well, that was a one liner… but here is a patch!
Thank you in advance for reviewing.

Checking for != 'views' isn't smart. Realname should only interfere if it's a known plugin that uses the known autocomplete. Only 'base' does that, so it should check for == 'basic'.

Actually, what realname 'should' do is override Drupal's autocomplete menu callback, not override widgets' #autocomplete_path. That way all the autocomplete elements get the realname magic, but only if it replaces the normal boring Drupal autocomplete. If you override a widget, you never know what you're overriding exactly.

Normally a widget type user should be safe. There may be edge cases, but we can workaround for these.

If it overrides the menu callback, all widgets using the normal user autocomplete will have been 'upgraded' automatically. Now you'd have to explicitly set the #autocomplete_path to realname's. Maybe not so good for backward compatibility though.

The only known issue seems to be a problem where Realname fights with OG. One of them must win.

I think the root cause is a missing field API function in entity reference and that I had no other option.

The only known issue seems to be a problem where Realname fights with OG. One of them must win.

No, in my case, I'm not using OG and still have the problem that realname auto complete always expose all users without respecting the view used by entity reference.

Unfortunately I'm not familiar enough with autocmoplete to be able to really follow your discussion.

@julou: Can you share a detailed repro case, please.

Yeah, it has nothing to do with OG. The use case is very simple:

1. Create an entity reference with handler type Views instead of Basic, and filter the View on a role.
2. The autocomplete is overridden with Realname's, the View isn't used, the role filter isn't used, very wrong results.

#12 fixes it (altough I used #13 because it's correcter), but then you have no Realname magic =( (but at least you have the correct View with the correct role filter)

@Dhamub Aaaaaaaw yeah! I didn't know Entity Reference had that! That is truly perfectly awesome! Thanks mang!

What does this mean?

It means nothing to the issue. If you apply patch #12, it can work a way I didn't know. But you need the patch.

I said Needs Work in #13, because I think that's more correct, but if nobody agrees, patch in #12 is RTBC.

Just run into this as well. The patch in #12 is correct, if the autocomplete is coming from an entityreference view then the override is not needed as realname can be applied manually in the UI as outlined in #21.

Specifically the code in realname_field_widget_form_alter() breaks entityreference views in that it replaces the view with an unfiltered list of all users. To be honest you could just remove the realname_field_widget_form_alter() function entirely and state that people need to use a view if they want realname integration for entiryreference autocomplete fields.

@hass: Did you say this issue "Needs work" because of comment #25? I have come across this issue myself and need to have this fixed at some point and would love to help however I can.

What are your thoughts?

@NancyDru, do you have any ideas on what the proper fix for this problem could be? The patch #12 has worked for the development team I work for, but it sounds like it isn't the _proper_ way of fixing this issue. What would you suggest?

IMHO realname_field_widget_form_alter() should be removed entirely, because the widget is none of Realname's business. If it really has to, it has to be sure it only overrides the standard autocomplete. Checking for != 'views' is not enough, because there are more ER widgets out there. They must NOT be overridden, so only == 'base' should be overridden.

Patch attached.

Again, last time, Realname shouldn't do this at all IMO.

Could you add tests, please? We schould make sure this does not break in future.

The patch in #29 worked for me to solve this issue with the EntityReference module autocomplete: https://www.drupal.org/node/1978274

Patch from #29 works good on my current project for realname of version "7.x-1.3".

Also this patch looks good (I think @rudiedirkx absolutely correct - we should override only 'base' field behavior).

Needs tests

I stumbled upon this from the entityreference issue queue, totally unaware Realname may be causing such issue.
Glad to report the patch in #29 worked great for me.
Thanks @rudiedirkx

patch from #29 works great - this should be default expected real name behaviour +1 for commit

@hass Could you point me in the right direction, test-wise? How do I test a widget? Build and render an entity form?

Not sure how, but we should make sure everything is shown and maybe does not throw errors.

patch from #29 works great for me on version 7.1.3 .

Patch #29 resolved the issue with Entity Reference fields for me as well.

I encountered this same issue, and after looking in the code (before finding this issue) I came to the same conclusion, that Real Name should not alter the Entity Reference autocomplete widget when using Views to select the entities, since we can format the results however we want in Views. Patch is simple, focused, and does exactly that.

Manually applied to v1.3 and it worked for me!

Thanks for all the hard work on this one!

@hass

Man patch is 2 years old and everybody confirms that it is working without complaints so what is the real reason to not set status as RTBC???

@nimek: