ModelMultipleChoiceField fail when the foreignkey remote model is a child class of anohter model

[Omar BENHAMID]

The issue

When a child model is used as a foreign key, forms with ModelMultipleChoiceField (not setting to_field_name) will systematically fail to validate submited values.

Reproduction

models.py

class A(models.Model):
      pass

class B(A):
      pass

class C(models.Model):
      fkfield = models.ForeignKey(B, on_delete=models.CASCADE)

Create form with MultipleChoiceField of the foreignkey fkfield and it will systematically fail to validate.

Reason

ModelMultipleChoiceField uses value.pk in prepare_value to generate choices but uses "to_field_name" in _check_data for validation.
default to_field_name is by default related_field.field_name which is "<parent>_ptr" in the case of inheriance child models, which points to the parent itself (not the pk).

ModelMultipleChoiceField fail when the foreignkey remote model is a child class of anohter model

Workaround

Use to_field_name = 'pk' when ModelMultipleChoiceField is created.

Proposed fix

Use PK in validation like in generation of choices.

Spotted in 3.2

[David Sanders]

Sorry but 3.2 is no longer supported 🤷‍♂️

[Omar BENHAMID]

There is indeed an issue, the question is the use cas support it : is it worth solving ?

Currently django-slick-report builds a search form using a ModelMultipleChoiceField backed by a simple ForeignKey field (the aim is to select mutliple values for an "OR-search"). The way values are genrated for the choices of the widgets are the same only if the field is iterable (so one to many but not many to one) and this often works well except when model inheritence is used.

This is exists in 5.1 and I can try to provide demo project but before is : is this usage supported ? Shall we try to make this part more robust in django?

[David Sanders]

My advice would be to create a discussin on the Django forum in the "Django Internals" category where other folks will be able to see the issue: ​https://forum.djangoproject.com/c/internals/

We'll be able to gauge whether it's worth fixing by the responses people give.