Reference Blocked Users adds one permission that lets an editor reference blocked accounts, not just active ones, in the "Authored by" field and in any custom entity reference field that points at users. It requires Drupal 11.3 or 12 and has no other module dependencies.
The gap it closes
Drupal core's user reference widget quietly filters blocked accounts out of the autocomplete unless the person doing the searching holds Administer users — a permission that also grants far more than reference access, which is exactly why most sites will not hand it to a content editor. The practical result: an editor trying to set "Authored by" to a former employee's account, or attribute a historical piece to a writer who has since been blocked, cannot find that user at all.
There is an open core issue for adding a configuration option to custom reference fields, but the "Authored by" field ships with no configuration form to attach one to — the core issue explains why. This module sidesteps the gap with a single permission that applies to both cases at once.
Requirements
| Requirement | Value |
|---|---|
| Drupal core | ^11.3 || ^12 |
| Other modules | None declared |
Version 2 rebuilt the selection plugin around the modern #[EntityReferenceSelection] PHP attribute rather than the old annotation — the discovery mechanism Drupal 12 dropped support for entirely — so it installs cleanly on 12 without the "no longer supported" fatal that hits modules still carrying only an annotation. Sites still on Drupal 9 or 10 need the project's 1.x branch — this is a branch-support note from the project record, not something the code itself can confirm.
How the permission behaves
The module registers a selection plugin, default:reference_blocked_users, that extends Drupal core's own UserSelection rather than replacing it. It only changes behavior for one specific combination: a user who does not hold Administer users but does hold the new Reference blocked users permission. Everyone else — including anyone who already has Administer users — gets exactly Drupal core's stock behavior, unchanged.
What the widened query actually returns
For a user with the new permission, the plugin builds its own entity query instead of delegating to core: every account regardless of blocked status, filtered only by whatever role restriction the field's own configuration specifies, with the anonymous user excluded unless the field is explicitly configured to include it.
Searching by email, not just username
This is the one behavior change in version 2.0: the autocomplete now matches the typed text against the user's email address as well as their username, using an OR condition across both columns. Drupal core's own selection handler only ever matches the username, so an editor who remembers a contributor by their email rather than their login name previously had no way to find them at all.
Setting it up
composer require drupal/reference_blocked_users
drush en reference_blocked_users -yThen grant the Reference blocked users permission to whichever role should see blocked accounts in reference fields — typically an editor or content-manager role, not the roles that already carry Administer users. There is no separate configuration screen; the permission is the entire interface.
Proving it works on your own site
- Create a role without Administer users, grant it Reference blocked users, and assign it to a test account.
- On the Article content type, add a plain entity reference field targeting users, alongside the built-in Authored by field.
- Block one of your test user accounts.
- Log in as the role you just built and open the article edit form.
- Both the Authored by field and your custom field should now offer the blocked account in autocomplete — and typing part of its email address should find it too.
If the blocked account still does not appear, check that the role genuinely lacks Administer users — that permission takes the core code path, not this module's, and core's default query already shows blocked accounts to administrators, which can make the module look inactive when it is simply not the plugin doing the work.
Common questions
Does this weaken user privacy or security in any way?
No new data is exposed. Blocked accounts already exist in the system and are visible to anyone with Administer users; this permission only extends who can pick them from a reference field's autocomplete, and it is a separate, narrowly scoped permission an administrator assigns deliberately.
Will it work with fields other than "Authored by"?
Yes. Any entity reference field configured to target the user entity type picks up the widened selection once the field's reference method uses the default selection plugin and the viewing user holds the permission.
Do I need to configure anything on the field itself?
No. The behavior change lives entirely in the selection plugin and the permission — there is nothing to toggle on the field's own reference settings.
What happens on Drupal 10?
This 2.x line requires 11.3 or 12 and will refuse to install below that. The project maintains a 1.x branch for older cores.
Need a hand with a Drupal permissions or access problem?
Reference Blocked Users is free, like the rest of my contributed work on drupal.org. If your project has a messier access-control problem than one permission can solve, that is the kind of work I take on directly.
Read about my Drupal services, see what a Drupal developer actually does day to day, or get in touch.
