The Allow new terms widget setting applies to every role, so there is no way to say that one role may add terms while another may only pick from the ones that exist.
No new permission of our own. The widget asks the access handler of the referenced entity type whether the current user may create an entity in the autocreate bundle, which for taxonomy is the core create terms in vocabulary permission, and which any module that alters entity access can answer as well. New terms are offered only when the setting is on, an autocreate bundle is configured and that check passes.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 3112680-no-create-permission.png | 42.64 KB | rajab natshah |
| #15 | 3112680-check-entity-create-access.patch | 2.01 KB | cyberwolf |
| new-term-permission.patch | 2.2 KB | nkoporec |
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
rajab natshahComment #3
rajab natshahComment #4
bassplaya commentedIs this available for Drupal 7 as well?
If you have it, please provide.
Much obliged.
Comment #5
mohammad-fayoumiThanks, @nkoporec the patch works fine.
Comment #6
rajab natshahThe patch needs to be updated to latest 2.0.x branch
Comment #7
rajab natshahComment #8
daveianoI think that this is the wrong direction. We should not introduce new permissions, we should use the available core permissions, e.g. for taxonomy:
create terms in [vocabulary]
So the widget should check which is the target bundle and type and then if the user has the correct permission to create new entities of this specific tape + bundle.
Comment #11
tostinni commentedFollowing comment from @daveiano adding the test if the user can add new terms to the current vocabulary.
Comment #12
rajab natshahComment #13
cyberwolf commentedRelated to core issue #3372919: Entity reference selection handlers do not check the "create" access for autocreated entities.
Comment #14
cyberwolf commentedAttaching a patch that properly uses the entity access handler (so the existing permissions in core, or altered by modules in the proper way).
Comment #15
cyberwolf commentedUpdated patch that properly uses the field's target type instead of a hardcoded 'taxonomy_term'.
Comment #17
rajab natshahThank you, Nejc for reporting and for the first patch, David for pointing at the core permissions, Nicolas for the earlier merge request, and cyberwolf for the patch that uses the entity access handler.
Went with the access handler rather than a permission of our own, so the core create terms in vocabulary permission decides, and any module that alters entity access is respected. The new merge request also carries the entity type manager into the widget instead of calling the service statically.
Tested on Drupal 11.4 with an unlimited term reference field and a role that may create the content but not create terms in that vocabulary: the widget stops offering the new term and nothing is created. Granting that one permission to the same role brings the behaviour back, and the node saves with the new term.
To review, test, then merge.
Comment #18
rajab natshahMR !34 needed rebasing before it could safely go in, and that is now done. Pipeline is green.
Why it needed it. The branch was cut on 28 August and 2.1.x has moved fourteen commits since. Its diff against the branch tip was deleting seven feature files, reverting the stylesheet build from PostCSS back to gulp and SASS, and removing settings including show entity ID, the parent hierarchy and the selection handler override. Merging it would have quietly undone #3181219, #3263472, #3100411, #3226157, #3314294, #3307367, #3056545, #3535541, #3176316, #3298376, #3152123, #3268207, #3534094 and #3061562.
CI was green throughout, because the branch was perfectly consistent with itself. It was just eight days behind. Worth remembering that a green pipeline says nothing about what a merge would remove.
What I did. Rebased onto current 2.1.x. Six conflicts, all the same shape: the branch tip injects the selection plugin manager and this work injects the entity type manager, and both are wanted, so both are kept. On the second one I took your approach of requiring the injected service rather than my earlier fallback, since yours is cleaner.
The diff is now four files and ninety five lines: the access check, its feature file, the tagger role and the cucumber user. Nothing else.
Checked on Drupal 11.4.5. As a user who may create articles but has no create terms permission, the widget stops offering to add a term and the list simply reads "No results found". Existing terms are still selectable. As an administrator the offer is still there.
That last part is also exactly what #3465063 and #3568757 report, so this closes all three.
Prepared with AI assistance (Claude), reviewed and driven by the maintainer.
Comment #20
rajab natshahMerged into 2.1.x as
b08ed19. Thank you tostinni for the original patch and for the long wait on this one.The widget now asks the access handler of the referenced entity type whether this user may create one, before it offers to add anything new. Where the answer is no, the suggestion list simply reports no results instead of promising a value the save would refuse.
Rather than adding a permission of its own, it follows the core permissions already there, so "create terms in [vocabulary]" and anything a contrib module does to entity access are both respected without configuring the same thing twice.
This also settles #3465063 and #3568757, which were the same fault seen from the content side and the taxonomy side.