[Django] #17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name attribute
Django
attribute
--------------------------------+--------------------
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+--------------------
When extracting data from existing model instance `ModelForm` ignores
`to_field_name` attribute of `ModelMultipleChoiceField` fields and always
extracts values as a list of primary keys (see
https://code.djangoproject.com/browser/django/trunk/django/forms/models.py?rev=17434#L127)
One of the problems caused by this behaviour is that options in multiple
select widget are not selected. Here's a small test case to illustrate
this:
{{{
# models.py
from django.db import models
class Foo(models.Model):
slug = models.CharField(max_length=40, unique=True)
title = models.CharField(max_length=40, unique=True)
class Bar(models.Model):
foos = models.ManyToManyField(Foo)
}}}
{{{
# tests.py
from django.test.testcases import TestCase
from django import forms
from models import Foo, Bar
class TestModelMultipleChoiceWithFieldName(TestCase):
def setUp(self):
self.instance = Bar.objects.create()
self.instance.foos.add(Foo.objects.create(title="Spam",
slug="spam"))
self.instance.foos.add(Foo.objects.create(title="Ham",
slug="ham"))
self.instance.foos.add(Foo.objects.create(title="Eggs",
slug="eggs"))
def test_without_field_name(self):
class Form(forms.ModelForm):
foos = forms.ModelMultipleChoiceField(Foo.objects.all())
class Meta:
model = Bar
form = Form(instance=self.instance)
self.assertEquals(
str(form["foos"]),
'<select multiple="multiple" name="foos" id="id_foos">\n'
'<option value="1" selected="selected">Spam</option>\n'
'<option value="2" selected="selected">Ham</option>\n'
'<option value="3" selected="selected">Eggs</option>\n'
'</select>'
)
def test_with_field_name(self):
class Form(forms.ModelForm):
foos = forms.ModelMultipleChoiceField(Foo.objects.all(),
to_field_name="slug")
class Meta:
model = Bar
form = Form(instance=self.instance)
# Fails! Options aren't selected.
self.assertEquals(
str(form["foos"]),
'<select multiple="multiple" name="foos" id="id_foos">\n'
'<option value="spam" selected="selected">Spam</option>\n'
'<option value="ham" selected="selected">Ham</option>\n'
'<option value="eggs" selected="selected">Eggs</option>\n'
'</select>'
)
}}}
I am preparing a patch now.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
attribute
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by andreyfedoseev):
* needs_better_patch: => 0
* has_patch: 0 => 1
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:1>
Django
attribute
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* stage: Unreviewed => Design decision needed
Comment:
I'm not sure what to do with this ticket.
`to_field_name` is an internal API. I'd like to know if it's possible to
trigger a bug by using only public APIs. But the patch appears to be an
improvement.
This needs more thought.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:2>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
* cc: marc.tamlyn@… (added)
Comment:
I came across this today - I would like the patch to be applied. I know
I'm messing with an internal API but it'd be good if it 'just worked'.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:3>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by poswald):
I think there is a pretty strong case to be made that this kind of
functionality should be documented and added to Django's public API. Even
without going that far, it certainly seems more clean to not make the
assumption that the pk is the way field names are looked up, if an
attribute is being used elsewhere in the code.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:4>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jacob):
* stage: Design decision needed => Accepted
Comment:
The patch is an improvement, so internal API or not I think it should go
in.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:5>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by bmispelon):
* cc: bmispelon@… (added)
* needs_better_patch: 0 => 1
Comment:
This was reported again recently with a slightly different perspective
(the goal was to hide the pk from the end-user): #20202
In that ticket, I came to the conclusion that it was a documentation issue
and proposed the following patch:
https://github.com/bmispelon/django/compare/ticket-20202
The existing patch does not apply cleanly anymore because of commit
e44ab5bb4fd3aa826ca4243a8ea9fd7125800da2 which was done as an
optimization.
The optimization is unfortunately not compatible with the OP's proposed
fix.
From my understanding, `model_to_dict` needs access to the form's field's
`to_field_name` which is a problem because the current implementation is
only passed a model instance and two lists of field names (one to include
and one to exclude).
It's possible to hack something that makes the OP's test pass but it's
quite ugly: https://gist.github.com/bmispelon/5329758
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:6>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by valtron2000@…):
* cc: valtron2000@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:7>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by nav@…):
* cc: nav@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:8>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by tchaumeny):
Replying to [comment:6 bmispelon]:
> From my understanding, `model_to_dict` needs access to the form's
field's `to_field_name` which is a problem because the current
implementation is only passed a model instance and two lists of field
names (one to include and one to exclude).
I just run on that bug on production (Django 1.6) with a
`ModelChoiceField` and after looking at the code I came to the same
conclusion. It would be nice to do something about it.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:9>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by timgraham):
#26405 is a duplicate.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:10>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by drepo):
(Since #26405 is referenced here) I'd say `to_field_name` should not be an
internal API, it is a very natural use case for a developer building on
Django. Think of an `input[type=text]` with an autocomplete as you type
feature. Not uncommon and very user-friendly when the selection list is
more than 20-30 items (thousands in our case and not unheard of in most
enterprise(y) use cases).
In such a scenario one would have to maintain a dual state - store the
`id` of the foreign key somewhere (possibly `input[type=hidden]`) and
display the text in the original. Also significant client side script
would be needed to synchronize changes between the two fields.
Furthermore, the developer experience of rendering the form may not be as
simple as `{{ form }}`.
The problem gets more complicated in case of M2M relations, where more
state has to be managed on client side. More code -> more bugs and reduced
productivity.
One could argue that `[type=hidden]` may be eliminated by using
transformations at the View level, but it is not a DRY approach and does
not give the same automation as most of the forms framework does. And I
don't like "injecting" random code snippets in an otherwise pretty elegant
and nearly declarative Django forms.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:11>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.3
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by andreyfedoseev):
* cc: andrey.fedoseev@… (added)
Comment:
Unfortunately, the proposed patch doesn't work anymore. The original idea
was to have `model_dict` to return "raw" values provided by
`f.value_from_object()` and let the form fields to the rest. Now it's
impossible because `ManyToManyField.value_from_object` was changed so that
it always returns a list of `pk`s instead of a `QuerySet`. See
https://github.com/django/django/commit/67d984413c9540074e4fe6aa033081a35cf192bc
I've created a new pull request GitHub with the following changes:
1. Revert `ManyToManyField.value_from_obj` back to return a `QuerySet`
instead of a list of `pk`s
2. Remove the obsolete tests for `model_to_dict` performance optimization.
3. Add tests to ensure that `to_field_name` is handled correctly.
I don't know why the special case with `pk`s existed in `model_to_dict` in
the first place.
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:12>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: closed
Component: Forms | Version: 1.3
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"81963b37a92ef583b9f725f1a78dd2ca97c1ab95" 81963b37]:
{{{
#!CommitTicketReference repository=""
revision="81963b37a92ef583b9f725f1a78dd2ca97c1ab95"
Fixed #17657 -- Made ModelForm respect ModelMultipleChoiceField's
to_field_name.
Follow up to 67d984413c9540074e4fe6aa033081a35cf192bc.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:13>
Django
attribute
Reporter: andreyfedoseev | Owner: nobody
Type: Bug | Status: closed
Component: Forms | Version: 1.3
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by Tim Graham <timograham@…>):
In [changeset:"ded502024191053475bac811d365ac29dca1db61" ded5020]:
{{{
#!CommitTicketReference repository=""
revision="ded502024191053475bac811d365ac29dca1db61"
[1.10.x] Fixed #17657 -- Made ModelForm respect ModelMultipleChoiceField's
to_field_name.
Follow up to 67d984413c9540074e4fe6aa033081a35cf192bc.
Backport of 81963b37a92ef583b9f725f1a78dd2ca97c1ab95 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/17657#comment:14>