Custom realname autocomplete support does not respect the roles filter nor the user permission to access blocked users, as the Core user autocomplete plugin does.
Proposing here a patch to fill these gaps.
| Comment | File | Size | Author |
|---|---|---|---|
| #37 | 2927167-37.patch | 12.4 KB | junaidpv |
| #36 | 2927167-36.patch | 11.73 KB | junaidpv |
| #31 | 2927167-31.patch | 11.53 KB | jayelless |
| #29 | 2927167-29.patch | 11.55 KB | jzavrl |
| #22 | interdiff.txt | 892 bytes | plopesc |
Issue fork realname-2927167
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
plopescComment #3
plopescComment #4
hass commentedThat is not possible I think. Core does not implement this as I know, too. Or can you show the core function that allows this type of filtering?
If this is done every node form would break as it can no longer populate the author name just as one example. An author can be a user that is filtered by your code and than missing in autocomplete.
Comment #5
plopescGood morning,
I'm just trying to replicate the behavior in
Drupal\user\Plugin\EntityReferenceSelection::buildEntityQuery()method that you're replacing withRealNameAutocompletecontroller::getMatches()method.In the original method, autocomplete results are filtered by "status", not returning blocked users if the user has no administer user permissions and adds role filtering if enabled in EntityReference field.
Here are the steps to reproduce:
Same process to reproduce the blocked users issue, but blocking one of the users and trying to create the node with a user without "administer users" permission.
Hope this helps
Comment #6
hass commentedThan it is ok, but we need tests to make sure all this stuff works properly. I think I have not reviewed D8 about this, in D7 this is not the case and this was a forward port what explains why it may be missing.
Marking needs work for full test coverage.
Comment #7
plopescHello,
I was rethinking the approach I followed and discovered that we could have a simpler and less intrusive approach.
Instead of replacing the whole autocomplete route controller and implement the custom code there, we could implement a new EntityReferenceSelection plugin for realname extending the user one and adding the necessary customizations to support realname.
Attaching the patch, so you can add tour input.
Thank you.
Comment #8
hass commentedGreat simplification, but we still need tests.
Comment #9
plopescHello hass,
Tests added extending the ones in User module.
Thank you
Comment #10
hass commentedShouldn't this DisplayName?
Shouldn't this DisplayName?
Comment #11
plopescLabel is fine, given that label method reads the label_callback property of the entity definition, whose value is user_format_name. That function is a wrapper for getDisplayName().
Also, this is the way Drupal core handles this test.
Comment #12
hass commentedMaybe we can use functions that are easier to read.
Comment #13
plopescI believe he usage of
label()method here makes the tests more solid, given that not only confirms thatgetDisplayName()works, it tests thelabel()anduser_format_name()integration as well.In any case, if you want me to change it, let me know and I'll be happy do to the changes.
Comment #14
plopescHello @hass
Any update on this?
We would appreciate a lot if we have this patch committed to the module codebase.
Thank you
Comment #15
lasensio commented@plopesc
Patch in #9 is working perfectly in my use case. I spent 2 hours wondering why the role filter wasn't working as expected.
Searching for issues in my code, or related stuff in core, etc. I started to get really mad until I stumbled upon this issue, and your patch.
Many thanks for this, you saved my day.
Comment #16
amietpatial commented#2 applied successfully and working fine .
Comment #17
mahtab_alam commentedPatch #2 applied succesfully
Comment #18
plopescI encourage you to use the latest patch instead of #2. The architecture is more flexible and you can avoid some conflicts with other 3rd party modules in the future.
Comment #19
hass commentedSound not logic to me. getDisplayName() uses user_format_name() to generate the users real name with a fallback to the username. Can you explain how label can make it more solid, please?
Comment #20
plopesc@hass I believe label is more consistent, because it ensures the
getDisplayName()behavior.User::label()invokesuser_format_name(), whose implementation is this:So, when you call
label(), you are callinggetDisplayName()under the hood. I believe that we are testing both methods at the same time when usinglabel()instead ofgetDisplayName(). Also that's the approach followed by Drupal core to test this kind of plugins.Anyway, if you are not convinced, let me know and I will update the tests to match your requirements. The aim of this issue is to improve the existing logic, not to discuss about the best way to load the user entity display name.
Thank you
Comment #21
hass commentedI‘m not convinced with #2629286: Use getDisplayName() for user names consistently in mind.
Comment #22
plopescOK, here is the updated version of the patch.
Thank you.
Comment #23
hass commentedSomething is wrong with the patch. I ran the RealnameEntityReferenceTest on my machine and it always fails with
InvalidArgumentException: Invalid database prefix: in Drupal\Core\Test\TestDatabase->__construct() (Line 81 in \core\lib\Drupal\Core\Test\TestDatabase.php).and
Notice: Undefined offset: -2 in Drupal\Core\Test\TestStatus::label() (Line 59 in \core\lib\Drupal\Core\Test\TestStatus.php)and
Sounds like Drupal.org is not running your test what is another problem.
ConfigCacheTag.phpshould be namedRealnameConfigCacheTag.phpAside why is installSchema() in setUp()? If you install a module all tables should be installed automatically.
Comment #24
hass commentedPlease update the patch so we can commit it.
Comment #25
plopescHello,
I just run the test or again and it seems that tests are being executed and green, I think.
Could you please confirm it checking the Jenkins output??
Thank you
Comment #26
plopescComment #27
hass commented#23
Comment #28
c7bamford commentedIt appears that this patch causes autocomplete fields to search by account name, not the real name. Without the patch, autocomplete works on both real name and account name.
Comment #29
jzavrl commentedI've reapplied the patch against latest dev version and updated the plugin and tests. The realname search didn't work because the realname entity selection wasn't even selected. According to
web/core/lib/Drupal/Core/Entity/Annotation/EntityReferenceSelection.phpyou need to use the$groupin the annotation if you wish to extend an existing selection.Comment #31
jayelless commentedPatch in #29 no longer applies. Re-rolled for latest dev release.
Comment #32
m.lebedev commentedComment #33
manuel garcia commentedComment #35
w01f commentedThis seems to be a related issue for the most recent module version - https://www.drupal.org/project/realname/issues/3276281
Comment #36
junaidpvRe-rolled for the 2.0.0-beta2 and latest 2.x branch.
Comment #37
junaidpvRe-rolled for 2.0.0.
Comment #38
loze commentedTested. The patch applies and works as advertised.
+1 for this
Comment #39
loze commentedComment #44
loze commentedI created MR16 from the patch in #37 to help move this along.