Problem/Motivation
If a reference field has a limited cardinality and uses the autocomplete widget in the entity form, then the user can enter more values than the field allows, and the surplus values are discarded silently when the form is submitted.
Steps to reproduce
To reproduce:
- create a reference field, say on article nodes
- set its widget to autocomplete
- create a new article node
- enter one node title in the widget and let it autocomplete
- enter a comma and start typing another node title
- the widget lets you do this: it should not.
- save the node
- the node saves: it should not. The form should fail validation
- edit the node: only the last entered node title is shown
- check the DB: only the last entered node was saved in the field value
Proposed resolution
The form should fail validation when too many values have been entered in the autocomplete widget.
| Comment | File | Size | Author |
|---|---|---|---|
| #32 | 2951134-after_patch-MR_2362.mov | 2.29 MB | abhijith s |
| #32 | 2951134-before_patch-MR_2362.mov | 4.29 MB | abhijith s |
Issue fork drupal-2951134
Show commands
Start 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:
Comments
Comment #2
cilefen commentedA broken or incorrect form submission is major. I feel like I’ve seen this issue reported already but I have not searched as of writing this.
Comment #3
joachim commentedI had a search but didn't find anything matching.
I assumed critical because data the user enters is silently lost.
Comment #4
sathish.redcrackle commentedI have attached the patch file. So if use enters multiple values with comma seperated, it will return the first id.
Comment #5
sathish.redcrackle commentedReattached the patch file.
Comment #6
joachim commentedThat's changing the autocomplete behaviour for ALL fields. We need to change it only for fields with a cardinality limit.
And there should be a validation error when the user has tried to enter more items than the field's cardinality.
Comment #7
sathish.redcrackle commentedAdded test only patch to prove by adding comma separated entity values.
Comment #8
joachim commentedI don’t really understand your patch. It seems to be testing that the *currrent* behaviour happens.
There *should* be a form error!
Comment #9
bibliophileaxePatch to set error if user enters multiple values.
Comment #17
guypaddock commentedCode for this bug was introduced in #1959806: Provide a generic 'entity_autocomplete' Form API element and #2434697: Remove UserAutocompleteController.
Comment #18
guypaddock commentedComment #19
guypaddock commentedWorking on this right now.
Comment #20
guypaddock commentedHere is a test to illustrate the problem. Unlike the earlier test-only patch, this one relies on the existing structure of other error-case tests and validates the error message text.
Comment #21
guypaddock commentedComment #23
guypaddock commentedComment #25
guypaddock commentedComment #26
guypaddock commentedBack to me for rework. It appears that a referenced node that has commas in its title (e.g., "Nodes, amirite?") loads without quotes surrounding its title, leading to a cardinality validation failure because the first part of the title is recognized as a separate node from the second part of the title.
Comment #27
guypaddock commentedAs it turns out, this was a red herring -- in our install, we also have a patch for #2796341: Entity reference field View output is not used for selected entity display applied, and that is what is causing the fields not to be quoted. Either way, this resulted in more test coverage for this ticket, so it's not a total bust.
Comment #28
guypaddock commentedComment #29
guypaddock commentedUpdated title.
Comment #30
guypaddock commentedSetting back to me to address test failures.
Comment #31
guypaddock commentedWrong ticket. Back to NR.
Comment #32
abhijith s commentedApplied MR 2362 on 9.4.x.The error is displaying for single value autocomplete widget after applying this patch.
Attaching screen recordings for reference.
Comment #34
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
This could use an issue summary update. Mainly what is the proposed solution to solve the issue? I see steps to reproduce but what was the solution decided upon? WIll help committers later?
Comment #35
joachim commentedAdded detail to IS.
Comment #36
smustgrave commentedCan someone verify if this is still an issue?
Just tested in Drupal 10.1 with a standard install
Changed article tags field to cardinality of 1
Created an article by adding TestA then TestB waiting for the autocomplete icon to go away each time
When I clicked save I get
Tags: this field cannot hold more than 1 values.
Comment #37
codechefmarcI also just tested on 10.0.3 with a standard install, similar details as smustgrave, and I also get the "Tags: this field cannot hold more than 1 values." message when trying to save the article. So, perhaps this is fixed in Drupal 10 which is great to hear.
Comment #38
guypaddock commentedCan someone confirm that there are tests for this behavior in 10.x? If not, I can at least reroll for the added test coverage.
Comment #39
smustgrave commentedFrom what I can tell searching for "hold more than" there are instances of test coverage. But this constraint in fieldItemList has been in for 5 years? That doesn't right.
Want to make sure we can move credit for everyone that helped work on this.
Comment #40
smustgrave commentedBrought this up in the #bugsmash channel and others reported they were able to replicate
From @rkoller
and
Comment #41
pameeela commentedYeah, confirmed it occurs with the regular 'Autocomplete' widget and not the tags style one.