#33489 closed Bug (invalid)
Autocomplete broken on ManyToManyField
Reported by: | Filipe | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 3.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've bumped into https://github.com/django/django/blob/3.2.8/django/contrib/admin/views/autocomplete.py#L42 after upgrading from django 3.1.5 to 3.2.8 (introduced in 3.2 looking at the tags, so adds up)
My current setup is a parent class:
# app "vulns" class Finding(models.Model): ... related_to = models.ManyToManyField('self', blank=True, help_text='Other findings related to this one')
And then child class (adding for completeness but not sure it matters)
# app "burp" class Finding(vuln_models.Finding): ...
vulns.Finding
has an admin model defined with search fields id
and title
When editing a burp.Finding (changeform) the autocomplete for related_to
sends related_to_rel+
as field_name
resulting self.source_field
being set to the ManyToManyRel
(not the ManyToManyField
).
The Rel has limit_choices_to
but it does not have a get_limit_choices_to
(while the Field does).
I've been trying to find if it's me doing something wrong in the model definition but it's pretty straightforward...
Change History (4)
comment:1 by , 3 years ago
Component: | Uncategorized → contrib.admin |
---|---|
Resolution: | → needsinfo |
Status: | new → closed |
Type: | Uncategorized → Bug |
comment:2 by , 3 years ago
So I've pushed a sample app (https://github.com/fopinappb/django-bug-reports/tree/main/autocompleteM2M_3.2) but was also unable to reproduce. I'll try to find the quirks in the original code and I'll update the ticket (if it's not something in the project code/setup)
comment:3 by , 3 years ago
ok, found the culprit line and it was not even in the custom theme, it was directly in the project code...
Should've started a sample app from the start and would've saved some bytes and bandwidth on this ticket :)
cheers
Thanks for the report, however I cannot reproduce this issue with described models. Can you provide a small sample project?