- First commit to issue fork.
- Status changed to Closed: outdated
9 months ago 6:53pm 6 August 2024 - ๐จ๐ฆCanada blanca.esqueda
The patch don't apply to Core 10.3.1
The patch in comment #20 is already included in Core 10: https://api.drupal.org/api/drupal/core%21modules%21user%21src%21Plugin%2... - ๐ฎ๐นItaly kopeboy Milan
The fix had not been included in core yet!
I applied the rerolled patch in #39, which still applies cleanly even to Drupal 10.3.6, and it worked fine, it just needs some clarification in the field help text imo..
When creating Entity reference fields on Users, this becomes the default:
You would assume from the description that the checked option will make users without the 'administer users' permission able to select blocked users. The opposite is true: the checked option, ie. by default, leaves core behaving like currently (you can't select blocked users unless you have the 'admin users' perm), but if unchecked it hides the blocked users on that field even to roles with the 'aminister users' permission.
So the feature is consistent with the original request, but we can improve the intuitiveness by reverting the label & description:
[ ] Exclude blocked users (unchecked by default - also, leave the "Include the anonymous user." as independent of this option)
Even if this option is not set, only users with the administer users permission may (view and) reference blocked users. - Status changed to Needs work
6 months ago 10:16am 28 November 2024 - ๐ณ๐ฟNew Zealand quietone
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
- ๐ท๐ดRomania claudiu.cristea Arad ๐ท๐ด
Please move this to a MR in order to be properly reviewed
- ๐ท๐ดRomania reszli Tรขrgu Mureศ
the current patch has incorrect comparison:
the status = 1 condition needs to be added if the include_blocked is false AND the user has no administer users permission
if the include_blocked is true OR the user has administer users permission, then it should not be added
so I re-rolled it for 10.x11.x already has an "include_blocked" setting on the selection handler, but it defaults to FALSE
that approach works for entity reference fields, where you can configure it,
but it does not work for the "Name (autocomplete)" views exposed filter
so IMHO the MR for 11.x should only contain a change for the default value to TRUE
but first we need to check why it was introduced with default FALSE