[Django] #18501: Custom fields as foreign keys fix
Django
----------------------------------------------+--------------------------
Reporter: msopacua | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: master
Severity: Normal | Keywords: RelatedField
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------------
Custom fields which have a different database representation as python
representation are not handled correctly when rendered as Select fields.
The underlying cause is that the value on the model that has the foreign
key is the database representation and it is not converted to python
representation when model_to_dict is called.
The ForeignKey field subclasses RelatedField and Field, but RelatedField
does not override it's value_from_object method to convert the value to
python.
--
Ticket URL: <https://code.djangoproject.com/ticket/18501>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: RelatedField | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by aaugustin):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Could you provide a test case ? Or at least a minimal code sample and
instructions to reproduce the problem?
That would be much easier for us than trying to rebuild an example from
your description.
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:1>
Django
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: RelatedField | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by msopacua):
Ok, so I'm unable to write a proper test case, because the ModelForm class
does not expose the bug but the admin change form does. So the admin does
something special, that I'm unable to figure out that exposes this bug.
Therefore I've provided an app "devices", that is a copy of the models
involved reduced to the size that they still expose the bug. The test case
therein as said, works properly. However, if one adds 'devices' to the
installed apps of a project, load the fixture and then browse to
http://localhost/admin/devices/devicepciid/1/ you will see that the vendor
is not selected. Applying the patch, reloading application and refreshing
the browser will show that the vendor is selected. I suspect the formfield
callback to be the culprit but can't really figure out how to make this
into a proper test case.
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:2>
Django
Reporter: msopacua | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: RelatedField | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by lrekucki):
This looks similar to #17214 and #17122.
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:3>
Django
Reporter: msopacua | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Keywords: RelatedField | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* stage: Unreviewed => Accepted
Comment:
Indeed, I could easily reproduce the problem with the example provided.
A quick scan of the models definition doesn't reveal anything suspicious.
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:4>
Django
Reporter: msopacua | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: RelatedField | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* cc: maa@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:5>
Django
Reporter: msopacua | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: RelatedField | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by maa@…):
* cc: maa@… (removed)
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:6>
Django
Reporter: msopacua | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: RelatedField | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by timo):
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:7>
Django
Reporter: msopacua | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Keywords: RelatedField | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => needsinfo
Comment:
As the sample project uses the deprecated `SubfieldBase` class to
construct the custom field, I am going to close this ticket as
"needsinfo". I suspect this issue may have been fixed since this ticket
was created as `UUIDField` has been introduced into core and we fixed
several related bugs.
Feel free to reopen with more details if it's still an issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/18501#comment:8>