Opened 7 weeks ago

Closed 6 weeks ago

Last modified 5 weeks ago

#30014 closed Bug (needsinfo)

Initialising disabled ModelChoiceField yields 'Select a valid choice'-error despite initialised option being valid

Reported by: thoha Owned by: nobody
Component: Forms Version: 1.11
Severity: Normal Keywords: forms, disabled field, error, to_field_name
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by thoha)

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, 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:

Change History (6)

comment:1 Changed 7 weeks ago by thoha

Description: modified (diff)
Keywords: to_field_name added

comment:2 Changed 7 weeks ago 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.

comment:3 Changed 6 weeks ago 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)

comment:4 Changed 6 weeks ago by Carlton Gibson

Resolution: needsinfo
Status: newclosed

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
>>> a_form.is_valid()
>>> 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.

comment:5 Changed 5 weeks ago by thoha

It seems to only occur when I try to use get_initial in If I use a custom init in 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.

comment:6 Changed 5 weeks ago 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.

Note: See TracTickets for help on using tickets.
Back to Top