When using an autocompletion element in an entity reference field widget, there is a feature to create entities automatically, in case the typed in labels of the entity aren't found. This is most commonly used to allow users to create new taxonomy terms if no matching ones are found.
While this makes sense for terms, it's a bit awkward for other entity types that can be created using only a label. Since many sites likely rely on this behavior, the fix should take into account existing field widgets and not require sites to grand wide sweeping permissions to what are now "low" or even anonymous uers.
Give a user access to an autocomplete entity reference field widget that references an entity type / bundle they do not have access to, and make sure to enable the autocreate feature. They should be able to create entities automatically by using the widget since the "create" access check isn't being performed.
Perform the "create" access check before creating new entities during entity reference autocomplete, without breaking existing sites.
Discuss impact on existing sites, write a patch.
"Respect create access, only users with the necessary permission can create new entities" checkbox appears on the field's Selection handler settings when "Create referenced entities if they don't already exist" is enabled. Enabled by default on new fields; left off on upgrades.
\Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection: new configuration key auto_create_check_access (default TRUE) returned by defaultConfiguration() and surfaced in buildConfigurationForm().DefaultSelection::createNewEntity() now throws \Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException when auto_create_check_access is TRUE and the current user lacks create access on the target bundle. The access check in the entity_reference_autocomplete widget was already client-side; this closes the path for callers that bypass the widget.auto_create_check_access key in handler_settings of entity_reference fields using the default selection handler (config schema: field.plugin.entity_reference_selection.default).system_post_update_set_auto_create_check_access() sets the key to FALSE on existing fields that already have auto_create but no stored auto_create_check_access, preserving current runtime behavior on upgrade.Entity reference fields with auto-create now check that the current user has create permission on the referenced bundle before autocreating. The new auto_create_check_access setting (per field, default TRUE) controls this. Upgraded sites keep their existing behavior because system_post_update_set_auto_create_check_access() sets the flag to FALSE on fields that already had auto-create enabled; site admins can opt in per field from the field's Selection handler settings.
| Comment | File | Size | Author |
|---|
Show commandsStart 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:
changes
Comments
Comment #2
berdir> While this makes sense for terms, it's a bit awkward for other entity types that can be created using only a label.
I think that's neither an issue nor relevant to this. Allowing auto-create is already an option on the field, if you don't need it or it doesn't make sense for the given entity type, then the setting can just be not enabled, it's off by default.
That's why I'm unsure what to do about this and if it's even really a bug as it is. A bug would require a "fix", which would definitely cause issues on many sites.
The only idea I have atm is to make it a feature, with a "[ ] Respect create access, only users with the necessary permission can create new entities", then have that off on existing fields and on by default on new ones?
Comment #3
berdirAlso, should this have a security tag?
Comment #4
catchThis also seems like the only way to handle both cases, but I can't really think of a use-case where you'd want this particular UX. You could have curated entity refs with autocomplete (which we already allow for), but then would you want admins using the autocomplete UI to create new ones? And if you really needed that, a custom/contrib widget might be an option rather than adding clutter to the UI here.
Another thing would be adding to the description of the existing setting to note that it doesn't require 'create' entity access - i.e. just document the existing behaviour a bit more explicitly.
Comment #5
james.williamsI've just created https://www.drupal.org/project/autocreate_access to fill this gap, so that site admins can configure access for different roles, so that some can create referenced items on the fly, whilst others cannot.
Comment #9
penyaskitoCreated MR. Separated concerns in 4 commits:
\Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::createNewEntityin case some child selection plugin is calling it directly. Which apparently even core does, as I had to amend some tests.Opening my own threads on the MR to highlight these.
Disclaimer: Used AI (Claude:claude-opus-4.7). It initially implemented the checks for the current user, but I assumed we wanted the assigned owner too. The shipped config it's all LLM-generated, but I verified it. Same for upgrade path + tests, which I had to clean up but was technically correct. Extra hardening it's completely mine, as I assumed that if we want to protect on both of the owner and current user access, we would need to be extra-cautious here too.
Comment #10
penyaskitoTest feedback + @berdir feedback agree on not needing to check access for the owner, just the current user.
Comment #11
penyaskitoChecking access for the current user (deliberately not checking create access for the owner of the newly created entity)
Updated IS.
Comment #12
penyaskitoComment #13
smustgrave commentedThis one appears to need a rebase and most likely would need a CR please
Thanks.
Comment #14
penyaskitoRebased + draft change record.
Comment #15
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. The merge request has merge conflicts and cannot be merged. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.