[user_display_name module integration] Edit form should use user display name not account name

I'm sorry, I'm not familiar with the GitLab workflow.

Can you post a patch, please?

Hey @salvis, I've attached the associated patch file.

For what it's worth, I generated it by clicking Merge request !3 in #3, then clicking the blue Code dropdown on top right of GitLab page, then selecting Plain Diff, which triggers a ".diff" file download.

re-roll of original merge request, as patch

The patch in #6 causes a white-screen-of-edit for me when I try to edit the Access Control on a page I have with an ACL user specified.

Here is an updated patch that resolves that.

That said, I do not see any altered behavior. I am still seeing the "username" value for the user in question on my page's ACL config. For what it is worth, my user records only have username, password, and email. So, I am not entirely sure what is meant/intended to be pulled by the "label" logic in this patch.

@salvis, let me know what you think.

@salvis, I installed user_display_name, enabled it, and set up a display name on the user in questions. I refreshed the Content Access page and it does indeed now show the display name.

For those using this module, I think this functionality is actually pretty slick. The user search box results also show the display name. However, you must still search the account name to find the user. So, you can't actually search by display name. If you think that's a bug, feel free to remove RTBC (p.s. I wouldn't know how to fix that).

Thank you for your efforts here, xeM8VfDh!

However, you must still search the account name to find the user. So, you can't actually search by display name.

Yes, I'm pretty sure this schizophrenic behavior would come back to us as a bug, even though it's probably a missing feature in the user_display_name module.

I have additional concerns here:

1. It's unclear whether this works with D8, and I don't want to spawn a new branch just because of this.

2. It's unclear whether it can work correctly. The first part of the patch eliminates accessing {users_field_data} directly by using the existing API, which is generally an improvement, even if it takes a little-used contrib to actually get a tangible benefit. However, the second part continues to use {users_field_data} — this has a bad smell.

However, you must still search the account name to find the user. So, you can't actually search by display name.

Yes, I'm pretty sure this schizophrenic behavior would come back to us as a bug, even though it's probably a missing feature in the user_display_name module.

Anyone customising the display name should also probably be customising the plugin that handles user entity reference autocomplete, it's their problem if they haven't, not acl's problem.

@jonathanshaw the fact that I don't know what you're talking about says... something.

I am not use of the user_display_name module, so maybe I am missing something obvious to others. But it seems like a pretty simple and intuitive module (just add display name fields to Drupal Core's user records). The fact that these names get used/displayed is simple and intuitive. That said, it is NOT intuitive that, after having set these display names, you need to still search by username in the ACL/Content Access search widget. It sounds like you're saying there is no way ACL can change this, and it's someone else's problem. I'm not familiar enough with the tool chain to know whose problem it is, or how to do the "customization" you suggest in #10.

I don't know how to contribute further here, or if there is even more work to be done. I will let you and @salvis hash it out and, if you all need me to test anything, let me know.