[Django] #30014: Initialising disabled ModelChoiceField yields 'Select a valid choice'-error despite initialised option being valid
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.11
Severity: Normal | Keywords: forms, disabled
Triage Stage: | field, error
Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
I have a form with a ModelChoiceField that gets initialised to a specific
value using get_initial in that form's View. This value is a valid choice
for that Model. I don't want the user to be able to change the option on
the form, but it needs to be displayed nonetheless.
When I set disabled=True on that field in forms.py, submitting the form
yields the following error:
<ul class="errorlist"><li>fieldname<ul class="errorlist"><li>Select a
valid choice. That choice is not one of the available
choices.</li></ul></li></ul>.
Firstly, I would like to comment on the general quality of the error
message, as it is not very useful: It does not return ''which'' choice it
considers invalid. Including this information would make the message much
more informative, and would avoid sending people on a wild goose chase to
discover what the message could possibly mean.
Secondly, if a field is disabled but does contain a valid choice,
validating the form should work and not trigger an error.
This is probably related to the bugfix for this bug:
https://code.djangoproject.com/ticket/28387
--
Ticket URL: <https://code.djangoproject.com/ticket/30014>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.11
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* keywords: forms, disabled field, error => forms, disabled field, error,
to_field_name
Old description:
> I have a form with a ModelChoiceField that gets initialised to a specific
> value using get_initial in that form's View. This value is a valid choice
> for that Model. I don't want the user to be able to change the option on
> the form, but it needs to be displayed nonetheless.
>
> When I set disabled=True on that field in forms.py, submitting the form
> yields the following error:
>
> <ul class="errorlist"><li>fieldname<ul class="errorlist"><li>Select a
> valid choice. That choice is not one of the available
> choices.</li></ul></li></ul>.
>
> Firstly, I would like to comment on the general quality of the error
> message, as it is not very useful: It does not return ''which'' choice it
> considers invalid. Including this information would make the message much
> more informative, and would avoid sending people on a wild goose chase to
> discover what the message could possibly mean.
>
> Secondly, if a field is disabled but does contain a valid choice,
> validating the form should work and not trigger an error.
>
> This is probably related to the bugfix for this bug:
> https://code.djangoproject.com/ticket/28387
New description:
I have a form with a ModelChoiceField that gets initialised to a specific
value using get_initial in that form's View. This value is a valid choice
for that Model. I don't want the user to be able to change the option on
the form, but it needs to be displayed nonetheless.
When I set disabled=True on that field in forms.py, submitting the form
yields the following error:
<ul class="errorlist"><li>fieldname<ul class="errorlist"><li>Select a
valid choice. That choice is not one of the available
choices.</li></ul></li></ul>.
Firstly, I would like to comment on the general quality of the error
message, as it is not very useful: It does not return ''which'' choice it
considers invalid. Including this information would make the message much
more informative, and would avoid sending people on a wild goose chase to
discover what the message could possibly mean.
Secondly, if a field is disabled but does contain a valid choice,
validating the form should work and not trigger an error.
Edit: Adding the **to_field_name** option to the form field fixes the
problem. However, when disabled=True is not present, this is not required.
This is probably related to the bugfix for this bug:
https://code.djangoproject.com/ticket/28387
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:1>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.11
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
Can you please include code to reproduce the issue? (or ideally, a test
for Django's test suite). Also, you should verify the issue against Django
2.1 or master, if possible.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:2>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.11
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by thoha):
Because this is for work on a commercial project, I can't give the exact
code, but I'll try to provide generic examples.
The form field get intialised in the FormView via:
{{{
def get_initial(self):
"""
Returns the initial data to use for forms on this view.
"""
initial = super(FormView, self).get_initial()
if self.formfield1 is not None:
initial['formfield1'] = Model.objects.get(pk=self.formfield1)
return initial
}}}
In this case a primary key value is passed, but the problem also occurs
when I pass a value for another field in the model.
The working code in the form is:
{{{
formfield1 = forms.ModelChoiceField(queryset=Model.objects.all(),
to_field_name='corresponding field name in the model', label='item to
use', disabled=True)
}}}
If I leave out the disabled=True I can leave out to_field_name:
{{{
formfield1 = forms.ModelChoiceField(queryset=Model.objects.all(),
label='item to use')
}}}
Then the field initialises properly, too.
This however will fail:
{{{
formfield1 = forms.ModelChoiceField(queryset=Model.objects.all(),
label='item to use', disabled=True)
}}}
The problem does not occur if I initialise the field via a custom __init__
in the form itself. In that case I can leave out to_field_name:
{{{
selected_record = Model.objects.filter(some_flag=True).first()
selected_field_item = selected_record.field1
self.fields['formfield1'] = forms.CharField(max_length=64, label='Field
1', initial=selected_field_item, disabled=True)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:3>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Component: Forms | Version: 1.11
Severity: Normal | Resolution: needsinfo
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => needsinfo
Comment:
Can you reduce this to a minimal example?
As far as I can see the underlying behaviour between `disabled` and
`initial` is correct:
{{{
>>> from django import forms
>>>
>>> class AForm(forms.Form):
... c = forms.ChoiceField(choices=(("a","A"), ("b", "B")),
disabled=True)
...
>>> a_form = AForm(data={}, initial={"c":"a"})
>>> a_form.is_bound
True
>>> a_form.is_valid()
True
>>> a_form.errors
{}
>>> a_form.cleaned_data
{'c': 'a'}
}}}
Thus there must be something more particular about your case.
Happy to review if we can pin that down.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:4>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Component: Forms | Version: 1.11
Severity: Normal | Resolution: needsinfo
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by thoha):
It seems to only occur when I try to use get_initial in views.py. If I use
a custom init in forms.py I can do whatever I want, but get_initial tends
to be glitchy. I'm afraid I can't get any closer than that.
Even if the problem with get_initial can't be tracked down, fixing the
unhelpful error message itself would be an improvement, too.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:5>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Component: Forms | Version: 1.11
Severity: Normal | Resolution: needsinfo
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
> Even if the problem with get_initial can't be tracked down, fixing the
unhelpful error message itself would be an improvement, too.
thoha, the main problem here is that we can't reproduce your problem with
the details you provided. If you can provide a minimal test project that
reproduces your issue against Django 2.1 we'll certainly investigate more
but at this point nothing proves Django is at fault.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:6>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* cc: Etienne Chove (added)
* version: 1.11 => 2.1
* resolution: needsinfo =>
Comment:
Here is the test example I wrote in
{{{tests/forms_tests/field_tests/test_modelchoicefield.py}}} reproducing
this bug:
{{{
from django.forms import ModelChoiceField, Form
from django.test import TestCase
from ..models import ChoiceOptionModel
class ModelChoiceFieldTest(TestCase):
def test_disabled_field_1(self):
opt1 = ChoiceOptionModel(12345)
opt1.save()
class MyForm(Form):
field = ModelChoiceField(
queryset=ChoiceOptionModel.objects.all(), disabled=True,
initial=opt1)
self.assertTrue(MyForm({}).is_valid())
}}}
When {{{disabled}}} is {{{True}}}, the function {{{to_python}}} is called
with initial value already having model type.
Here's new version of function {{{ModelChoiceField.to_python}}} in
{{{django/forms/models.py}}} :
{{{
= def to_python(self, value):
= if value in self.empty_values:
= return None
+ if type(value) is self.queryset.model:
+ return value
= try:
= key = self.to_field_name or 'pk'
= value = self.queryset.get(**{key: value})
= except (ValueError, TypeError,
self.queryset.model.DoesNotExist):
= raise ValidationError(self.error_messages['invalid_choice'],
code='invalid_choice')
= return value
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:7>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
Hi Etienne.
Thanks for the test case. It's not quite working as expected I think...
I get exactly the same failure with `disabled` `True` or `False`. (i.e.
changing it doesn't make the test pass.)
Can you double check and adjust?
(I'll leave it open for the moment.)
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:8>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Etienne Chove):
Replying to [comment:8 Carlton Gibson]:
> Hi Etienne.
>
> Thanks for the test case. It's not quite working as expected I think...
>
> I get exactly the same failure with `disabled` `True` or `False`. (i.e.
changing it doesn't make the test pass.)
>
> Can you double check and adjust?
> (I'll leave it open for the moment.)
Hi Carlton,
Tahnk for your analysis.
If you write **disabled=True**, the test fails due to the bug described
here. If you set **disabled=False**, the test fails because there're no
data given to the form.
Here's the code failing only for **disabled=True** :
{{{
from django.forms import ModelChoiceField, Form
from django.test import TestCase
from ..models import ChoiceOptionModel
class ModelChoiceFieldTest(TestCase):
def test_disabled_field_1(self):
opt1 = ChoiceOptionModel(12345)
opt1.save()
class MyForm(Form):
field = ModelChoiceField(
queryset=ChoiceOptionModel.objects.all(), disabled=False,
initial=opt1)
self.assertTrue(MyForm({"field": str(opt1.pk)}).is_valid())
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:9>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
This might be solved by [https://github.com/django/django/pull/10948 a
documentation clarification] regarding what values should be used for
initial data (primary keys rather than model instances).
While it seems [https://github.com/django/django/commit/b3dc3a0106#diff-
0dae03f028452ebf691f40214bceb395R129 some efforts] were made to support
model instances an initial values, I'm not certain if that's a good path
to continue down given the increased complexity.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:10>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Etienne Chove):
I think either we implement completely the **initial** paramter with a
model instance (adding the 2-lines as proposed) or we do not implement at
all, remove code and throw exception if user set it not as a **pk**.
Leaving it work in **enabled** but not in **disabled** fields is, in my
mind, a bad solution because developpers will have same issue in the
future.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:11>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Etienne Chove):
I really disagree just adding notice in the doc.
In this case, when we want inial from a blanked instance field, we should
add many lines each time to test if ther's a **pk** or if it is **None**:
{{{
class MyForm(Form):
if the_object.the_filed is None:
initial = None
else:
initial = the_object.the_filed.pk
# or initial = the_object.the_filed and the_object.the_filed.pk or
None
field = ModelChoiceField(
queryset=ChoiceOptionModel.objects.all(), disabled=False,
initial=initial)
}}}
Allowing initial as a model instance is a really good idea, it reduces 4
lines each time.
Another patch, if we do not want to use model object everywhere, would be
to evaluate type in the **__init__** method of the **ModelChoiceField** so
we just store **pk**.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:12>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
Hi Etienne.
I am sympathetic to your point. Looking at your test-case, it is a little-
strange that it accepts the model instance in the one-case but not in the
other.
The addition Tim offers for the docs is right too: don't give a form data
that it would never normally receive and expect it to work. (Garbage in,
garbage out.)
So the thought about mapping to the `pk` in init seems a possibility. (We
want to allow passing instances, but lets move from that as quickly as
possible.)
The other thought is, yes, don't allow passing instances at all...
The difficulty here is "why is it as it is? & what breaks?" Answering that
definitively is why this is still "Unreviewed" (We have looked at it. 🙂)
How about you put your patch (with test) in a PR on Github? That way the
CI will tell us the "what breaks?" bit.
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:13>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Etienne Chove):
Hi,
I'll be on hollidays next week. I'll try to build a pull request when
back.
Etienne
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:14>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
Reporter: thoha | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage: Accepted
field, error, to_field_name |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:15>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: assigned
Component: Forms | Version: 2.1
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage: Accepted
field, error, to_field_name |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => assigned
* owner: nobody => Etienne Chove
* has_patch: 0 => 1
Comment:
Pull request posted [https://github.com/django/django/pull/11003 here]
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:16>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: assigned
Component: Forms | Version: 2.1
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage: Accepted
field, error, to_field_name |
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:17>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: assigned
Component: Forms | Version: 2.1
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage: Accepted
field, error, to_field_name |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:18>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: assigned
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage: Accepted
field, error, to_field_name |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* version: 2.1 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:19>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: forms, disabled | Triage Stage: Accepted
field, error, to_field_name |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> I have a form with a ModelChoiceField that gets initialised to a specific
> value using get_initial in that form's View. This value is a valid choice
> for that Model. I don't want the user to be able to change the option on
> the form, but it needs to be displayed nonetheless.
>
> When I set disabled=True on that field in forms.py, submitting the form
> yields the following error:
>
> <ul class="errorlist"><li>fieldname<ul class="errorlist"><li>Select a
> valid choice. That choice is not one of the available
> choices.</li></ul></li></ul>.
>
> Firstly, I would like to comment on the general quality of the error
> message, as it is not very useful: It does not return ''which'' choice it
> considers invalid. Including this information would make the message much
> more informative, and would avoid sending people on a wild goose chase to
> discover what the message could possibly mean.
>
> Secondly, if a field is disabled but does contain a valid choice,
> validating the form should work and not trigger an error.
>
> Edit: Adding the **to_field_name** option to the form field fixes the
> problem. However, when disabled=True is not present, this is not
> required.
>
> This is probably related to the bugfix for this bug:
> https://code.djangoproject.com/ticket/28387
New description:
I have a form with a ModelChoiceField that gets initialised to a specific
value using get_initial in that form's View. This value is a valid choice
for that Model. I don't want the user to be able to change the option on
the form, but it needs to be displayed nonetheless.
When I set disabled=True on that field in forms.py, submitting the form
yields the following error:
<ul class="errorlist"><li>fieldname<ul class="errorlist"><li>Select a
valid choice. That choice is not one of the available
choices.</li></ul></li></ul>.
Firstly, I would like to comment on the general quality of the error
message, as it is not very useful: It does not return ''which'' choice it
considers invalid. Including this information would make the message much
more informative, and would avoid sending people on a wild goose chase to
discover what the message could possibly mean.
Secondly, if a field is disabled but does contain a valid choice,
validating the form should work and not trigger an error.
Edit: Adding the **to_field_name** option to the form field fixes the
problem. However, when disabled=True is not present, this is not required.
This is probably related to the bugfix for this bug: #28387
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:20>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
field, error, to_field_name | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:21>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: forms, disabled | Triage Stage: Ready for
field, error, to_field_name | checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"e7cdb0cd7eb5eb677af8dae7bfc6845186f861b0" e7cdb0c]:
{{{
#!CommitTicketReference repository=""
revision="e7cdb0cd7eb5eb677af8dae7bfc6845186f861b0"
Fixed #30014 -- Fixed ModelChoiceField validation when initial value is a
model instance.
Thanks Carlton Gibson for reviews.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:22>
Django
despite initialised option being valid
-------------------------------------+-------------------------------------
| Chove
Type: Bug | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: forms, disabled | Triage Stage: Ready for
field, error, to_field_name | checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"651299e1ef896210035cf9e6992b07aa02a5aac1" 651299e1]:
{{{
#!CommitTicketReference repository=""
revision="651299e1ef896210035cf9e6992b07aa02a5aac1"
[3.0.x] Fixed #30014 -- Fixed ModelChoiceField validation when initial
value is a model instance.
Thanks Carlton Gibson for reviews.
Backport of e7cdb0cd7eb5eb677af8dae7bfc6845186f861b0 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30014#comment:23>